Für ein sauberes Datenmodell gehe ich auf dieser Seite hin und her ...
Wenn wir zum Beispiel einen Genehmigungsworkflow verwenden, sagen wir in meiner Webanwendung, dass ich eine Seite habe, auf der ein Benutzer ein MyEntityObject zur Genehmigung kennzeichnen kann. MyEntityObject hat einige Eigenschaften, die seinen Genehmigungs-Workflow steuern, daher habe ich eine gemeinsame Hilfsmethode namens FlagForApproval(MyEntityObject eo) .
Soll die Seite FlagForApproval () aufrufen, um nur die erforderlichen Eigenschaften festzulegen, und dann SaveChanges () aufrufen, wenn sie fertig ist oder FlagForApproval () speichert die Änderungen?
Wenn die Hilfsmethode Änderungen speichert, scheint sie etwas mehr zu tun, als sie benötigt wird (was wäre, wenn es nur ein Schritt in einer Reihe von Operationen wäre?), aber gleichzeitig die Seite SaveChanges () aufrufen zu lassen. und die Daten an die Datenbank zu übergeben scheint, als könnte es als zu nah an Datenschicht Verantwortlichkeiten betrachtet werden.
Gedanken?
(Update: FWIW, bisher habe ich Hilfsprogramme SaveChanges () aufgerufen, so dass die Seite nur einen Satz von Ausnahmen hat, egal ob Validierung oder Daten.)
Meine aktuelle Meinung zu diesem Problem ist, dass der Business-Logik-Layer-Aufruf nach der Validierung von Daten immer Änderungen speichern soll. 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 ().
Ich bin genauso neugierig wie du, um zu sehen, was andere sagen, weil dieses Problem (und viele andere) mich geplagt haben, seit ich mit EF angefangen habe.
Der Schlüssel besteht darin, die Datenbank und die Dienstsprache 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 sich das Dienstprogramm als Service an und denken Sie nicht an die 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 machen.
Wenn es mehrere Schritte gibt, sollten Sie in jedem Schritt indirekt angeben, dass weitere Schritte möglich 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.
Beispiel:
LoadToBatchApproval (MyEntityObject eo)
ValidateApprovalBatch () ...
MoveBatchToProcessing () ...
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.
Tags und Links c# entity-framework database