Entwerfen datenbankbezogener Methoden, die besser zurückgegeben werden können: true / false oder betroffene Zeile?

Ich habe einige Methoden, die einige Datenänderungen in einer Datenbank durchführen (Einfügen, Aktualisieren und Löschen). Das ORM, für das ich vom Rückgabewert betroffene int-Werte für diese Art von Methode verwende. Was soll ich für "meine Methode" zurückgeben, um den Erfolgs- / Fehlerstatus der Operation anzuzeigen?

Betrachten Sie den Code, der Folgendes zurückgibt int:

A.1

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

    return affectedRows;
}

Dann Verwendung:

A.2

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

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

Vergleichen Sie mit boolean:

B.1

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

    return affectedRows > 0;
}

Dann Verwendung:

B.2

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

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

Welches (A oder B) ist besser? Oder Vor- / Nachteile von jedem?

Eine andere Möglichkeit besteht darin, ein Ergebnisobjekt anstelle von Basistypen zurückzugeben. Zum Beispiel:

OperationResult deleteResult = myOrm.deleteById(id);

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

Wenn Sie aus irgendeinem Grund die Anzahl der betroffenen Zeilen zurückgeben müssen, können Sie einfach eine Methode in OperationResult hinzufügen:

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

Dieses Design ermöglicht es Ihrem System, zu wachsen und neue Funktionen (Kenntnis der betroffenen Zeilen) aufzunehmen, ohne den vorhandenen Code zu ändern.

Die Rückgabe der Anzahl der betroffenen Zeilen ist besser, da hier zusätzliche Informationen zum Ablauf des Vorgangs angezeigt werden.

Kein Programmierer wird Ihnen die Schuld geben, weil er / sie dies schreiben muss, um zu überprüfen, ob er / sie während des Vorgangs einige Änderungen erhalten hat:

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

Aber sie werden Ihnen die Schuld geben, wenn sie die Anzahl der betroffenen Zeilen kennen müssen und erkennen, dass es keine Methode gibt, um diese Anzahl zu erhalten.

Übrigens: Wenn Sie mit "Fehler" einen syntaktischen Abfragefehler meinen (in diesem Fall ist die Anzahl der betroffenen Zeilen offensichtlich 0), ist das Auslösen der Ausnahme angemessener.

Ich würde keinen von ihnen empfehlen. Geben Sie stattdessen bei Erfolg nichts (void) zurück und lösen Sie bei einem Fehler eine Ausnahme aus.

Dies ist genau der gleiche Grund, warum ich bestimmte Mitglieder der Klasse als privat deklariere. Es erleichtert auch die Verwendung der Funktion. Mehr operativer Kontext bedeutet nicht immer besser, aber sicherlich komplexer. Je weniger Sie versprechen, desto mehr abstrahieren Sie, desto leichter ist es für den Kunden zu verstehen und desto mehr Freiheit haben Sie bei der Auswahl der Implementierung.

Die Frage ist, wie Erfolg / Fehler angezeigt werden kann. In diesem Fall reicht es aus, einen Fehler durch Auslösen einer Ausnahme zu signalisieren und bei Erfolg nichts zurückzugeben. Warum muss ich mehr bereitstellen, als der Benutzer benötigt?

Fehler / Ausnahmesituationen können auftreten und Sie müssen sich dann mit ihnen befassen. Ob Sie try / catch verwenden oder die Rückkehrcodes überprüfen, ist eine Frage des Stils / der persönlichen Präferenz. Die Ideen hinter try / catch sind: Trennen Sie den normalen Fluss vom außergewöhnlichen Fluss und lassen Sie Ausnahmen bis zu der Ebene sprudeln, wo sie am besten gehandhabt werden können. Wie viele bereits betont haben, hängt es also davon ab, ob ein Fehler wirklich außergewöhnlich ist oder nicht.

"Ist das besser als das?" ist keine nützliche Frage, wenn die beiden Alternativen nicht dasselbe tun.

Wenn Sie die Anzahl der betroffenen Zeilen kennen müssen , müssen Sie Version A verwenden. Wenn Sie dies nicht müssen, können Sie Version B verwenden. Alle Vorteile, die Sie möglicherweise durch weniger Aufwand beim Schreiben von Code erzielen, sind jedoch bereits weg Sie haben sich die Mühe gemacht, beide Versionen in einem Online-Forum zu veröffentlichen!

Mein Punkt ist: Welche Lösung besser ist, hängt ganz von Ihren Anforderungen speziell für diese Anwendung ab, und Sie kennen diese Umstände viel besser als wir. Es gibt keine branchenweite, benutzerfreundliche, bewährte Methode, die im Allgemeinen nicht besser ist . du musst selbst darüber nachdenken. Und für eine Entscheidung, die so einfach zu überarbeiten ist wie diese, müssen Sie auch nicht allzu viel Zeit mit Nachdenken verbringen.

Zwei der wichtigsten Prinzipien beim wartbaren Software-Design sind KISS und YAGNI .

• KISS : Halte es einfach, dumm
• YAGNI : Du wirst es nicht brauchen

Es ist so gut wie nie eine gute Idee , in der Logik setzen Sie nicht sofort brauchen gerade jetzt . Jeff Atwood (Mitbegründer von StackExchange) hat unter vielen anderen darüber geschrieben , und meiner Erfahrung nach haben er und andere Befürworter dieser Konzepte völlig Recht.

Jede Komplexität, die Sie einem Programm hinzufügen, ist mit Kosten verbunden, die über einen langen Zeitraum bezahlt werden. Das Programm wird schwieriger zu lesen, komplexer zu ändern und leichter für Fehler einzuschleichen. Fallen Sie nicht in die Falle, Dinge "nur für den Fall" hinzuzufügen. Es ist ein falsches Sicherheitsgefühl.

Sie werden selten beim ersten Mal einen Code richtig machen. Änderungen sind unvermeidlich; Das Hinzufügen einer spekulativen Logik zur defensiven Vorbereitung auf unbekannte zukünftige Eventualitäten schützt Sie nicht davor, Ihren Code umgestalten zu müssen, wenn sich herausstellt, dass die Zukunft anders verläuft als erwartet. Die Wartung unnötiger / bedingter Logik ist eher ein Problem der Wartbarkeit als eine spätere Umgestaltung, um fehlende Funktionen hinzuzufügen.

Da Ihr Programm derzeit nur wissen muss, ob die Operation erfolgreich war oder fehlgeschlagen ist, ist Ihre vorgeschlagene Lösung B (Rückgabe eines einzelnen Booleschen Werts) der richtige Ansatz. Sie können es später jederzeit umgestalten, wenn sich die Anforderung ändert. Diese Lösung ist die einfachste und hat die geringste Komplexität (KISS) und macht genau das, was Sie brauchen, und nichts weiter (YAGNI).

Die ganzen Zeilen oder ein Fehlerstatus

Ziehen Sie in Betracht, die gesamten Zeilen zumindest als Laufzeitoption zurückzugeben. In DB-Einfügungen müssen Sie möglicherweise die eingefügten Daten überprüfen, da sie sich häufig von den Daten unterscheiden, die Sie an die DB gesendet haben. Zu den gängigen Beispielen gehören automatisch generierte Zeilen-IDs (die die App wahrscheinlich sofort benötigt), von der Datenbank festgelegte Standardwerte und Ergebnisse von Triggern, wenn Sie diese verwenden.

Auf der anderen Seite, wenn Sie die zurückgegebenen Daten nicht benötigen, dann brauchen Sie auch nicht die betroffene Zeilenanzahl, da es für das Ergebnis von 0. nicht hilfreich, wenn es Fehler gibt, dann müssen Sie zurückkommen, welche Art von Es ist ein Fehler aufgetreten, der mit den Grundsätzen Ihres Projekts zur Fehlerbehandlung übereinstimmt (Ausnahmen, numerische Fehlercodes usw.). Es gibt jedoch gültige Abfragen, die sich korrekt auf 0 Zeilen auswirken (dh "Alle abgelaufenen Bestellungen löschen", wenn tatsächlich keine vorhanden sind).