Argumente gegen Erstellen oder Aktualisieren

Question

Kürzlich hat jemand angegeben, dass sie alle Creates sollte CreateOrUpdates sein. Instinktiv dachte ich schlecht, aber jetzt versuche ich herauszufinden, ob ich Gründe habe.

Situation

interface IService{ 
    void Create(Object a); 
    void Update(Object a); 
    } 

oder

interface IService{ 
     void CreateOrUpdate(Object a); 
    } 

Mein erster Gedanke ist, wenn man alles CreateOrUpdate implementiert dann haben Sie keine Kontrolle, wenn jemand versehentlich falsche Daten oder Concurrency Probleme sendet, wo jemand ändert ein " primäre "Feld direkt vor dem Anruf Update ....

Aber wenn Sie diese Fälle entfernen, gibt es noch andere Nachteile?

Answer 1

Es scheint ziemlich einfach für mich: Wenn Sie besorgt über die versehentliche Erstellung von Datensätzen sind, verwenden Sie die beiden Methoden. Wenn Sie nicht besorgt sind, benutzen Sie einen.

Und wenn Sie nicht wissen, ob Sie betroffen sein sollten oder nicht, sind Sie nicht besorgt. Geh mit einer Methode.

Vielleicht ist das zu einfach, aber normalerweise ist das Ziel nur, um die Daten in die Datenbank zu bekommen.

Answer 2

In dem von uns verwendeten Framework gibt es kein Create, nur CreateOrUpdate. Wir sind nie auf einen Fall gestoßen, in dem wir nur Create benötigten.

Mit anderen Worten, es ist was angeboten wurde, also gingen wir damit, und es hat uns noch nicht gescheitert. System ist zwei Jahre alt mit rund 300 Tabellen.

In unserem Fall ändern wir Primärschlüssel nicht, und wenn der Primärschlüssel einer vorhandenen Zeile entspricht, ist es nicht falsch.

Answer 3

Ich arbeitete einmal an einer Anwendung für die Finanzberichterstattung, wo Updates verboten waren, alle Änderungen waren die Erstellung neuer Datensätze mit aktualisierten Daten. Dies war eine vollständige Überarbeitung aller Kontoänderungen.