Entity Framework Best Practices: Welche Schicht sollte SaveChanges() aufrufen?

Question

Für ein sauberes Datenmodell, ich bin hin und her auf diesem los ...

einen Genehmigungs-Workflow als Beispiel, lassen Sie sich in meiner Web-Anwendung, sie habe eine Seite, die für ein MyEntityObject einen Benutzer-Flag läßt die Genehmigung. MyEntityObject hat einige Eigenschaften, die den Genehmigungs-Workflow steuern, also habe ich eine gemeinsame Hilfsmethode namens FlagForApproval(MyEntityObject eo).

Sollte die Seite Anruf FlagForApproval() notwendigen Eigenschaften nur setzen und rufen Sie dann Savechanges() wenn es fertig ist, oder sollte FlagForApproval() die Änderungen speichern?

Wenn die Dienstprogrammmethode Änderungen speichert, scheint es etwas mehr zu tun, als es verlangt wird (was wäre, wenn es nur ein Schritt in einer Reihe von Operationen wäre?), Aber gleichzeitig die Seite SaveChanges aufzurufen () und die Daten an die Datenbank zu übermitteln scheint, als könnte es als zu nahe an Datenschicht Verantwortlichkeiten betrachtet werden.

Gedanken?

(Update: FWIW, so weit ich mit Dienstprogramm-Methoden aufrufen wurden Savechanges(), auf diese Weise die Seite nur ein Satz von Ausnahmen hat zu behandeln, ob die Validierung oder Daten.)

Answer 1

Meine aktuelle Meinung zu diesem Thema Problem besteht darin, dass der Geschäftslogik-Layer-Aufruf Änderungen nach dem Validieren von Daten immer speichert. Wenn der Benutzer auf die Schaltfläche Speichern klickt, übergebe ich alle Entitäten, die validiert werden müssen, an die BLL und entscheidet, ob SaveChanges() gespeichert werden soll.

Ich bin genauso neugierig wie du, um zu sehen, was andere sagen, weil dieses Problem (und viele andere) mich geplagt hat, seit ich mit EF angefangen habe.

Answer 2

Ich bin mir nicht sicher, ob es eine richtige oder falsche Antwort gibt, aber es fühlt sich sauberer (imo) an, dass FlagForApproval den Prozess zum Starten des Workflows behandelt. Dazu gehört, dass der DataLayer angewiesen wird, den Status des Objekts beizubehalten (z. B. SaveChanges). Dies setzt jedoch voraus, dass Sie Geschäftsanforderungen haben, die angeben, dass der Status nach dem Start eines Arbeitsablaufs beibehalten werden sollte. Wenn also etwas passiert (d. H. Server stürzt ab), wird der Arbeitsablauf vom letzten Schritt an fortgesetzt.

Answer 3

Der Schlüssel ist, Datenbank und Service Sprache zu trennen. Wenn die Hilfsmethode Änderungen speichern muss, tut sie dies, wenn sie nicht klarstellt, dass dies nicht der Fall ist und zusätzliche Schritte erforderlich sind. Das Dienstprogramm sollte keine Methode namens SaveChanges haben, es sollte prozessbezogene Methoden wie StartProcess oder LoadToBatch haben.

Sehen Sie das Dienstprogramm als mehr von einem Service und denke nicht, Datenbank. Das "FlagForApproval" klingt wie eine Datenbankoperation, versuchen Sie, die Methode als etwas wie "StartApprovalProcess" oder etwas anderes Prozessbezogenes zu denken. StartApprovalProcess würde alle Arbeit und Commits erledigen.

Wenn es mehrere Schritte gibt, machen Sie in jedem Schritt indirekt, dass möglicherweise weitere Schritte erforderlich sind. Nur der letzte Schritt wird ausgeführt. Obwohl der letzte Schritt alle Änderungen speichern kann, wird make wie ein Prozess wie move oder start gelesen.

Ex:

1. LoadToBatchApproval (MyEntityObject eo)

2. ValidateApprovalBatch() ...

3. MoveBatchToProcessing() ...