Entitäten von Entity Framework als Geschäftsobjekte verwenden?

Question

Ich verwende Entity Framework O/R-Mapper von Microsoft und verwende Entitätsklassen (generierte Klassen, die auf DB-Objekte abgebildet werden) als Geschäftsobjekte. Ist das in Ordnung? Bitte nennen Sie Ihre Vor- und Nachteile. Was ist im Falle einer WCF-Kommunikation zwischen Geschäftsschicht und Präsentation zu tun, wie werden diese Objekte als Datenelemente gesendet?

Answer 1

Zunächst einmal bin ich angesichts von 11.000 Frageaufrufen zum Zeitpunkt der Abfassung dieses Artikels etwas überrascht über den Mangel an Antworten und, bei allem Respekt, über die Qualität der Antworten, wenn man bedenkt, dass es sich um eine ziemlich einfache Frage handelt.

Nachdem ich mich nun ein wenig ausgelassen habe, möchte ich diese Frage(n) ansprechen, weil ich denke, dass sie heute mit der jüngsten Veröffentlichung von Entity Framework Code-First noch mehr gilt.

"Verwendung von Entity Framework Entitäten als Geschäftsobjekte?"

Bevor ich beginne, möchte ich ein paar Dinge klarstellen:

• Wenn Sie von "Geschäftsobjekten" sprechen, habe ich den Eindruck, dass diese Objekte, auf die Sie sich beziehen, Regeln oder Logik enthalten, die z. B. von einfacher Validierung (z. B. erforderliche Felder) bis hin zu komplexerer Logik (z. B. Verarbeitung von Steuern bei einer Kasse) reichen.

• Ich glaube nicht, dass ich Ihre Folgefrage zur WCF beantworten kann. Der Grund dafür ist einfach, dass ich Ihre Fragen über EF als Geschäftsobjekte objektiv beantworten werde, was mich dann subjektiv dazu zwingen würde, einen Standpunkt einzunehmen, der sich als widersprüchlich zu meinem Versuch erweist, die erste Frage wirklich und objektiv zu beantworten.

Nun aber zu Ihren Fragen zu EF als Geschäftsobjekte...

"Ich verwende den Entity Framework O/R-Mapper von Microsoft und verwende Entity Klassen (generierte Klassen, die auf DB-Objekte abgebildet werden) als Geschäfts Objekte. Ist das in Ordnung?"

Tut mir leid, es gibt hier einfach keine richtige oder falsche Antwort. Es kommt darauf an, welches Ziel Sie verfolgen und was Sie für die vernünftigste Lösung halten, wobei Sie die Vor- und Nachteile genau kennen müssen.

"Bitte nennen Sie Ihre Vor- und Nachteile"

Ich bin froh, dass Sie fragen! Ich antworte Ihnen gerne und hoffe, dass Sie angesichts der Vor- und Nachteile in der Lage sind, eine fundierte Entscheidung darüber zu treffen, ob Sie die Verwendung von EF für Ihre Geschäftsobjekte für "OK" halten oder nicht. Normalerweise würde ich die Vor- und Nachteile aufschlüsseln, um sie leicht verdaulich zu machen, aber ich glaube nicht, dass das hier angebracht ist, weil ich denke, dass wir einem so interessanten Thema, das auch mir sehr am Herzen liegt, Unrecht tun würden.

Lassen Sie mich zunächst kurz etwas Technisches sagen Sie können EF-Objekte als Geschäftsobjekte verwenden, es gibt nichts, was Sie technisch daran hindert, dies zu tun. Tatsächlich macht EF Code-First (CF) dies unglaublich einfach, indem es Ihnen erlaubt, POCOs zu erstellen und Ihnen die Möglichkeit gibt, Datenannotationen für einfache Validierung anzuwenden sowie IValidatableObject für komplexere Validierung zu implementieren. Ziemlich cool, oder?

Darin liegt der Kern der Diskussion.

EF oder jedes andere ORM ist für die Unterstützung der Datenverwaltung konzipiert. Seine Hauptaufgabe sind Daten und daher sind die Objekte, die Sie erstellen, datenzentriert. Wenn Sie also versuchen, Ihre Objekte auch nach dem Verhalten zu entwerfen, stehen Sie vor einem kleinen Rätsel. Kurz gesagt heißt dieses Problem Impedanzfehlanpassung. Stellen Sie sich Folgendes vor: Sie haben zwei erforderliche Anwendungsfälle in Ihrer Anwendung:

1. Ein Bildschirm zum Bearbeiten eines Benutzers
2. Ein Steuerelement zur Anzeige einer schreibgeschützten Teilmenge von Benutzerinformationen

Wenn Sie EF (egal welche Variante) oder ein anderes ORM verwenden, werden Sie vielleicht dazu neigen, dasselbe "User"-Objekt zu verwenden, um die Möglichkeit zu haben, einen Benutzer zu speichern und einen Benutzer abzurufen, um die Untergruppe der schreibgeschützten Felder zu nutzen. Wahrscheinlich tun Sie dies aus einem von mehreren Gründen:

1. Wie bei vielen Entwicklern wurde uns während der Ausbildung der Gedanke eingepflanzt, dass die Konsolidierung des Codes von größter Bedeutung ist, oder vielleicht besser bekannt als DRY - Don't Repeat Yourself, und deshalb sehen Sie die Duplizierung von Code, z. B. von Eigenschaften, vielleicht in einem negativen Kontext.
2. ORMs, wie z.B. EF 4.1, haben technische Beschränkungen (und hackige Workarounds), wie z.B. das Mapping mehrerer POCOs/Objekte auf dieselbe Datenbanktabelle, was Sie dazu zwingt, sich über Ihre Überzeugungen hinwegzusetzen.
3. Es ist ein schneller und einfacher Weg, eine Anwendung zum Laufen zu bringen
4. Es "fühlt" sich richtig an

Das hat Vor- und Nachteile, und man kann das je nach Meinung positiv oder negativ sehen.

Ich nehme an, wenn Sie an die Normalisierung des Codes gegenüber dem Verhalten glauben, haben Sie großen Erfolg. Sie waren in der Lage, die Menge des Codes zu begrenzen und damit Zeit zu sparen, indem Sie ein einziges Objekt geschrieben haben, um Ihre Daten und Geschäftsfälle für diese Entität zu verarbeiten.

Und ich nehme an, wenn Sie an die Normalisierung von Verhalten über Code glauben, dann haben Sie kläglich versagt. Indem Sie Code einsparen, haben Sie die Gestaltung von Objekten nach ihren Zuständigkeiten geopfert, was möglicherweise die Verwaltung erschwert und die Kosten für die Wartung erhöht.

Unabhängig von Ihrer Meinung können wir uns wahrscheinlich alle darauf einigen, dass dieses Geschäftsobjekt mehrere Aufgaben übernommen hat und das Verhalten (nicht die Daten!) des Objekts bestenfalls zweitrangig ist. Seine Hauptaufgabe ist die Verwaltung von Daten und seine Nebenaufgaben sind die Verarbeitung einfacher und komplexer Geschäftsregeln, die mit der Bearbeitung eines Benutzers und der Anzeige von schreibgeschützten Benutzerinformationen verbunden sind. Wenn im objektorientierten Design (OOD) das Design eines Objekts durch seine Identität und sein Verhalten charakterisiert wird, dann könnte dieses Objekt ein verwirrtes Individuum sein, da es sich nicht an die eigentliche Definition von OOD hält.

Aus technischer Sicht ist zu bedenken, dass jedes Mal, wenn Sie das Benutzerobjekt anfordern, eine erhebliche Menge an Overhead anfällt. Dazu gehören z. B. alle Eigenschaften und Geschäftsregeln, wenn nur eine Teilmenge der schreibgeschützten Informationen angezeigt wird.

Was hat das alles mit der Frage zu tun, ob ich EF zur Darstellung meiner Geschäftsobjekte verwenden sollte oder nicht?

Nun Obwohl es technisch möglich ist, gibt es unterschiedliche Philosophien (einige gut, einige schlecht) darüber, ob Sie EF oder ein anderes ORM verwenden sollten, um Ihre Geschäftsobjekte darzustellen oder nicht. Ich habe oben eine Zusammenfassung gegeben, die auf den Kern dieser Philosophien abzielt, aber sie sind viel detaillierter von Personen wie Rocky Lhotka und Martin Fowler dokumentiert.

Welche Richtung Sie einschlagen, hängt höchstwahrscheinlich von der Anwendung ab und kann aus philosophischer Sicht davon abhängen, wie sehr Sie Idealist oder Pragmatiker sind. Damit will ich nicht sagen, dass man als Idealist oder Pragmatiker EF für Business-Objekte verwenden sollte oder nicht - es hat einfach Auswirkungen auf Ihre Sichtweise.

Zum jetzigen Zeitpunkt deutet alles darauf hin, dass Microsoft EF für die Verarbeitung von Geschäftslogik entwickelt hat, und, ob richtig oder falsch, sie scheinen sich mehr in diese Richtung zu bewegen. EF entwickelt sich ständig weiter, und bestimmte technische Beschränkungen werden aufgehoben, so dass EF schließlich verwendet werden kann, um das Beste aus beiden Welten zu vereinen. Mit anderen Worten: Sie können irgendwann Ihren Kuchen haben und ihn auch essen.

Ich hoffe, das hilft.

Ich bin unterwegs, um eine Frage darüber zu beantworten, ob die Unkenntnis der Persistenz mit einem ORM lächerlich ist, wenn man bedenkt, dass es darum geht, Daten zu verwalten :-) Tut mir leid, ich konnte nicht widerstehen!

Answer 2

Ich verwende EF auf diese Art und Weise und ein nettes Feature ist, dass generierte Entitäten partielle Klassen sind, die es erlauben, sie auf eine Art und Weise zu erweitern, die ziemlich vor Regenerationsproblemen geschützt ist.

Werfen Sie auch einen Blick auf dieser Link auf MSDN der einige gängige Nutzungsszenarien mit EF in Bezug auf die Geschäftslogik beschreibt.

Answer 3

Das Entity-Framework wurde so konzipiert, dass die Entitätsobjekte als Geschäftsobjekte verwendet werden können, aber Sie sollten bedenken, dass die Geschäftsobjekte sowohl an die O/R-Technologie als auch an das EDM-Modell gebunden sind. In EF 1.0 gab es keine Unterstützung für _[Hartnäckigkeit - Ignoranz](http://blogs.msdn.com/dsimmons/pages/ef-faq-entity-classes.aspx#_Does_Entity_Framework "Does Entity Framework have support for "Persistence Ignorance"? What is Persistence Ignorance?")_ Szenarien, aber die Unterstützung wurde in 4.0 hinzugefügt. Sie können implementieren Schnittstellen wenn Sie keine ihrer Basisklassen verwenden wollen.

Ab .NET 3.5 SP1 sollten sie auch als Parameter- und Rückgabetypen in WCF-Dienstmethoden ohne zusätzlichen Code verwendbar sein.

Answer 4

Meiner Erfahrung nach haben wir EF-Objekte in der Geschäftsschicht unserer Anwendung verwendet, aber wenn wir über unsere WCF-Serviceschicht den Übergang zur Präsentationsschicht vollziehen, werden wir aus den EF-Objekten View-Objekte erstellen.

In unserem Fall wird nur die Ansicht an die Präsentationsschicht übergeben. Wir tun dies, um zu kontrollieren, wie die Daten präsentiert werden, und um eine defensive Validierung für Daten durchzuführen, die von der Präsentationsschicht kommen.

Wenn Sie EF-Objekte in der WCF-Transaktion verwenden, verlieren Sie den Objektkontext, mit dem das EF-Objekt verbunden war. Es gibt einige Bemühungen in CodePlex, die versuchen, bei diesem Problem zu helfen, aber ich bin nicht auf dem Laufenden mit ihren Bemühungen.

Answer 5

Zwei Einschränkungen, auf die ich gestoßen bin, sind zu beachten:

1. Vererbte Objekte können keine Navigationseigenschaften haben - d.h. wenn Sie eine Klasse "Person" und dann einen "Kunden" und einen "Lieferanten" haben, können diese Kunden und Lieferanten keine Navigationseigenschaften haben.

2. Methoden und berechnete Felder (alles in den partiellen Klassen) werden nicht über ADO.Net Data Services übertragen - wenn Sie auch ADO.Net Data Services verwenden, wird alles, worauf Sie die Entity Framework-Objekte in partiellen Klassen erweitern, nicht über ADO.Net Data Services übertragen werden.

Dies sind in der Regel keine Show-Stopper-Elemente (für Navigationseigenschaften verwenden wir im Moment keine Vererbung auf Entity-Frameworks), aber es könnte für Sie von Interesse sein. Ich habe die Hoffnung, dass eine zukünftige Version diese beiden Elemente aktivieren wird.