Progettazione di metodi correlati al database, che è meglio restituire: true / false o riga interessata?

Ho alcuni metodi che eseguono alcuni cambiamenti di dati in un database (inserire, aggiornare ed eliminare). L' ORM che sto usando restituisce valori int influenzati dalla riga per quel tipo di metodo. Cosa devo restituire per "il mio metodo", al fine di indicare lo stato di successo / fallimento dell'operazione?

Considera il codice che restituisce un int:

A.1

public int myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows;
}

Quindi utilizzo:

A.2

public void myOtherMethod() {
    ...
    int affectedRows = myLowerLevelMethod(id)

    if(affectedRows > 0) {
        // Success
    } else {
        // Fail
    }
}

Confronta con l'uso booleano:

B.1

public boolean myLowerLevelMethod(int id) {
    ...
    int affectedRows = myOrm.deleteById(id)
    ...

    return affectedRows > 0;
}

Quindi utilizzo:

B.2

public void myOtherMethod() {
    ...
    boolean isSuccess = myLowerLevelMethod(id)

    if(isSuccess) {
        // Success
    } else {
        // Fail
    }
}

Quale (A o B) è meglio? O pro / contro di ciascuno?

Un'altra opzione è quella di restituire un oggetto risultato invece dei tipi di base. Per esempio:

OperationResult deleteResult = myOrm.deleteById(id);

if (deleteResult.isSuccess()) {
    // ....
}

Con questo, se per qualche motivo devi restituire il numero di righe interessate, puoi semplicemente aggiungere un metodo in OperationResult:

if (deleteResult.isSuccess()) {
    System.out.println("rows deleted: " + deleteResult.rowsAffected() );
}

Questo design consente al tuo sistema di crescere e includere nuove funzionalità (conoscendo le righe interessate) senza modificare il codice esistente.

Restituire il numero di righe interessate è meglio perché fornisce ulteriori informazioni su come è proseguita l'operazione.

Nessun programmatore ti biasimerà perché deve scrivere questo per verificare se hanno subito delle modifiche durante l'operazione:

if(affectedRows > 0) {
    // success
} else {
    // fail
}

ma ti incolperanno quando dovranno conoscere il numero di righe interessate e si rendono conto che non esiste un metodo per ottenere quel numero.

A proposito: se per "fallimento" intendi un errore di query sintattica (nel qual caso il numero di righe interessate è ovviamente 0) allora lanciare l'eccezione sarebbe più appropriato.

Non consiglierei nessuno di loro. Invece, non restituire nulla (nulla) in caso di successo e generare un'eccezione in caso di errore.

Questo è esattamente per lo stesso motivo per cui ho scelto di dichiarare privati ​​alcuni membri della classe. Inoltre semplifica l'utilizzo della funzione. Più contesto operativo non significa sempre meglio, ma certamente significa più complesso. Meno prometti, più ti allontani, più è facile per il cliente capire e più libertà hai nella scelta di come implementarlo.

La domanda è come indicare successo / errore. In questo caso è sufficiente segnalare un errore generando un'eccezione e non restituire nulla in caso di successo. Perché devo fornire più di quanto l'utente ha bisogno?

Possono verificarsi guasti / situazioni eccezionali e quindi dovrai affrontarli. Sia che usi try / catch per farlo o per esaminare i codici di ritorno, è una questione di stile / preferenza personale. Le idee alla base di try / catch sono: separare il flusso normale da un flusso eccezionale e lasciare che le eccezioni arrivino al livello in cui possono essere gestite nel modo più appropriato. Quindi, come molti hanno già sottolineato, dipende dal fatto che il fallimento sia davvero eccezionale o meno.

"È meglio di così?" non è una domanda utile quando le due alternative non fanno la stessa cosa.

Se è necessario conoscere il conteggio delle righe interessate, è necessario utilizzare la versione A. Se non è necessario, è possibile utilizzare la versione B - ma qualsiasi vantaggio che si potrebbe ottenere in termini di minore sforzo di scrittura del codice è già andato da quando hai preso la briga di pubblicare entrambe le versioni su un forum online!

Il mio punto è: quale soluzione è migliore dipende interamente da quali sono i tuoi requisiti specifici per questa applicazione e conosci queste circostanze molto meglio di noi. Non esiste una scelta a livello di settore, sicura da usare, best practice, che non venga licenziata e che sia meglio in generale ; devi pensarci da solo. E per una decisione facilmente rivedibile come questa, non devi nemmeno passare tutto il tempo a pensare.

Due dei principi più importanti nella progettazione di software gestibili sono KISS e YAGNI .

• KISS : Keep it Simple, Stupid
• YAGNI : Non ne avrai bisogno

Non è quasi mai una buona idea mettere in logica ciò che non ti serve immediatamente in questo momento . Tra le altre persone, Jeff Atwood (un co-fondatore di StackExchange) ha scritto di questo , e nella mia esperienza lui e altri sostenitori di questi concetti hanno perfettamente ragione.

Qualsiasi complessità aggiunta a un programma ha un costo, pagato per un lungo periodo di tempo. Il programma diventa più difficile da leggere, più complesso da modificare e più facile da inserire per i bug. Non cadere nella trappola di aggiungere cose "per ogni evenienza". È un falso senso di sicurezza.

Raramente hai mai intenzione di ottenere qualsiasi codice giusto la prima volta. I cambiamenti sono inevitabili; l'aggiunta di una logica speculativa per prepararsi difensivamente a contingenze future sconosciute non ti proteggerà effettivamente dal dover riformattare il tuo codice quando il futuro si rivelerà diverso da quello che ti aspettavi. Mantenere la logica non necessaria / contingente è più un problema di manutenibilità che il refactoring in seguito per aggiungere funzionalità mancanti.

Pertanto, poiché sembra che per il momento tutto il tuo programma abbia bisogno di sapere se l'operazione ha avuto esito positivo o negativo, la soluzione proposta B (restituire un singolo booleano) è l'approccio corretto. Puoi sempre rifattorarlo in seguito se il requisito cambia. Questa soluzione è la più semplice e ha la più bassa complessità (KISS) e fa esattamente ciò di cui hai bisogno e niente di più (YAGNI).

Le righe intere o uno stato di errore

Considerare la restituzione di intere righe, almeno come opzione di runtime. Negli inserti DB potrebbe essere necessario ispezionare i dati inseriti, poiché spesso saranno diversi da quelli inviati al DB; esempi comuni includono ID di riga generati automaticamente (di cui l'app avrà probabilmente bisogno immediatamente), valori predefiniti determinati dal DB e risultati dei trigger se li si utilizza.

D'altra parte, se non hai bisogno dei dati restituiti, allora non hai nemmeno bisogno del conteggio delle righe interessate, poiché non è utile per il risultato di 0. Se ci sono errori, devi restituire che tipo di errore si è verificato, in modo coerente con i principi di gestione degli errori del progetto (eccezioni, codici numerici di errore, qualunque cosa); ma ci sono query valide che influiranno correttamente su 0 righe (ovvero "elimina tutti gli ordini scaduti" se in realtà non ce ne sono).