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

.net architecture entity-framework

Frage

Ich verwende den Entity Framework O / R Mapper von Microsoft und benutze Entitätsklassen (generierte Klassen, die DB-Objekten zugeordnet sind) als Geschäftsobjekte. Ist das ok? Bitte geben Sie Ihre Vor- oder Nachteile an. Was ist bei WCF-Kommunikation zwischen Business-Schicht und Präsentation zu tun, wie werden diese Objekte als Datenmitglieder gesendet?

Akzeptierte Antwort

Ich verwende EF auf diese Art und Weise und eine nette Eigenschaft ist, dass erzeugte Entitäten Teilklassen sind, die es ermöglichen, sie auf eine Weise zu erweitern, die vor Regenerierungsproblemen ziemlich geschützt ist.

Schauen Sie sich auch diesen Link auf MSDN an, der einige häufige Anwendungsszenarien mit EF in Bezug auf Business Logic beschreibt.


Beliebte Antwort

Zunächst einmal, mit 11k Fragestellungen zum Zeitpunkt der Abfassung dieses Artikels, bin ich ein wenig überrascht, dass es keine Antworten gibt, und bei allem Respekt die Qualität der Antworten, wenn man eine recht einfache Frage stellt.

Nun, da ich ein wenig gelüftet habe, möchte ich mich mit dieser Frage befassen, weil ich denke, dass sie heute mit der neuesten Version von Entity Framework Code-First noch mehr gilt.

"Entity Framework-Entitäten als Geschäftsobjekte verwenden?"

Noch ein paar Klarstellungen, bevor ich anfing:

  • Wenn Sie "Geschäftsobjekte" sagen, habe ich den Eindruck, dass diese Objekte, auf die Sie sich beziehen, Regeln oder Logik enthalten, die z. B. von der einfachen Validierung (dh erforderliche Felder) bis zu komplexer Logik (dh Bearbeitungssteuer an einer Kasse) reichen.

  • Ich glaube nicht, dass ich Ihre Folgefrage bezüglich der WCF beantworten kann. Der Grund dafür liegt einfach darin, dass ich Ihre Fragen zu EF als Geschäftsobjekte objektiv beantworten werde, was mich subjektiv dazu zwingen würde, eine Haltung einzunehmen, die sich als widersprüchlich erweist, wenn ich versuche, die erste Frage wirklich und objektiv zu beantworten.

Das heißt, auf Ihre EF als Geschäftsobjekte Fragen ...

"Ich verwende den Entity Framework O / R Mapper von Microsoft und verwende Entitätsklassen (generierte Klassen, die DB-Objekten zugeordnet sind) als Geschäftsobjekte. Ist das in Ordnung?"

Sorry, hier gibt es einfach keine richtige oder falsche Antwort. Es hängt davon ab, was Ihr Ziel ist und was Sie als das vernünftigste Design betrachten, während Sie die Vor- und Nachteile dieser Vorgehensweise verstehen.

"Bitte geben Sie Ihre Vor- oder Nachteile an"

Ich bin froh, dass du gefragt hast! Ich werde gerne antworten, und ich hoffe hier, dass Sie angesichts der Vor- und Nachteile eine fundierte Entscheidung treffen können, ob Sie der Meinung sind, dass die Verwendung von EF für Ihre Geschäftsobjekte „OK“ ist oder nicht. Normalerweise würde ich die Vor- und Nachteile ausreissen, um das „Verdauen“ zu vereinfachen. Ich denke jedoch nicht, dass dies hier angebracht ist, weil ich denke, dass wir ein so sehr interessantes Thema ungerecht machen würden was mir auch sehr am Herzen liegt.

Lassen Sie mich zunächst einmal technisch sprechen. Sie können EF-Objekte als Geschäftsobjekte verwenden. Technisch hindern Sie nichts daran, dies zu tun. EF Code-First (CF) macht dies unglaublich einfach, da Sie POCOs erstellen können und Datenanmerkungen für die einfache Validierung anwenden sowie IValidatableObject für komplexere Validierungen implementieren können. Ziemlich cool, wie?

Darin liegt der Kern der Diskussion.

EF oder ein beliebiges ORM unterstützt die Datenverwaltung. Seine Hauptverantwortung ist Daten und daher sind die von Ihnen erstellten Objekte datenzentriert. Wenn Sie also versuchen, Ihre Objekte auch durch Verhalten zu entwerfen, haben Sie ein kleines Rätsel zur Hand. In einer Nussschale wird dieses Rätsel Impedanzfehlanpassung genannt. Stell dir das vor; Sie haben zwei erforderliche Anwendungsfälle in Ihrer Anwendung:

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

Wenn Sie EF (eine beliebige Variante) oder einen beliebigen ORM für diese Angelegenheit verwenden, können Sie das gleiche "User" -Objekt verwenden, um die Fähigkeit zu speichern, einen Benutzer zu speichern, und einen Benutzer abrufen, um die Untermenge von schreibgeschützten Feldern abzurufen . Sie tun dies wahrscheinlich aus einem von mehreren Gründen:

  1. Wie viele Entwickler haben wir dieses Saatgut während der Schulung in unserem Gehirn gepflanzt. „Die Konsolidierung des Codes“ ist von größter Bedeutung oder vielleicht besser als DRY bezeichnet. Sie sollten sich nicht wiederholen als Eigenschaften, in einem negativen Kontext.
  2. Bei ORMs wie EF 4.1 gibt es technische Einschränkungen (und harte Umgehungen), z. B. das Zuordnen mehrerer POCOs / Objekte zu derselben Datenbanktabelle, wodurch Sie unabhängig von Ihren Überzeugungen dazu gezwungen werden.
  3. Es ist eine schnelle und einfache Möglichkeit, eine Anwendung zum Laufen zu bringen
  4. Es fühlt sich wie das Richtige an

Es gibt Vor- und Nachteile, und dies kann je nach Ihrer Meinung entweder positiv oder negativ sein.

Ich glaube, wenn Sie an die Normalisierung des Verhaltenskodex glauben, ist Ihnen dies sehr gelungen. Sie konnten die Menge an Code einschränken und möglicherweise Zeit sparen, indem Sie ein einziges Objekt für die Verarbeitung Ihrer Daten und Geschäftsanwendungsfälle für diese Entität schreiben.

Ich glaube, wenn Sie an die Normalisierung des Verhaltens gegenüber Code glauben, sind Sie kläglich gescheitert. Durch die Einsparung von Code haben Sie die Gestaltung von Objekten aufgrund ihrer Verantwortlichkeiten geopfert, was die Verwaltung erschwert und die Wartungskosten erhöht.

Unabhängig von Ihrer Meinung können wir uns wahrscheinlich alle einig sein, dass dieses Geschäftsobjekt mehrere Verantwortlichkeiten übernommen hat und das Verhalten (keine Daten!) Des Objekts bestenfalls sekundär ist. Seine Hauptaufgabe ist die Verwaltung von Daten, und seine sekundären Verantwortlichkeiten sind die Verarbeitung der einfachen und komplexen Geschäftsregeln, die mit der Bearbeitung eines Benutzers und der Anzeige von schreibgeschützten Benutzerinformationen verbunden sind. Wenn bei objektorientiertem Design (OOD) das Design eines Objekts durch seine Identität und sein Verhalten charakterisiert wird, könnte dieses Objekt ein verwirrtes Individuum sein, da es nicht an die Definition von OOD gebunden ist.

Aus technischer Sicht zu berücksichtigen: Wenn Sie das Benutzerobjekt anfordern, erben Sie einen erheblichen Overhead. Dies kann beispielsweise alle Eigenschaften und Geschäftsregeln umfassen, wenn nur eine Teilmenge von schreibgeschützten Informationen angezeigt wird.

Was hat das alles damit zu tun, ob ich EF verwenden sollte, um meine Geschäftsobjekte darzustellen?

Nun… Während dies technisch möglich ist, gibt es unterschiedliche Philosophien (einige gut, manche schlecht) darüber, ob Sie EF oder ORM verwenden sollten, um Ihre Geschäftsobjekte darzustellen. Ich habe eine Zusammenfassung der Kernthemen dieser Philosophien gegeben, die jedoch von Einzelpersonen wie Rocky Lhotka und Martin Fowler ausführlicher dokumentiert wird.

Die Richtung, die Sie einschlagen, hängt höchstwahrscheinlich von der Anwendung und von einer philosophischen Sicht ab. Sie kann davon abhängen, wie sehr Sie ein Idealist oder Pragmatiker sind. Das heißt, ich behaupte nicht, dass jemand, der Idealist oder Pragmatiker ist, davon abhängt, ob er EF für Geschäftsobjekte verwendet oder nicht - es wird sich einfach auf Ihre Einstellung auswirken.

Zum jetzigen Zeitpunkt deutet Microsoft darauf hin, dass EF für die Handhabung von Geschäftslogik ausgelegt ist. Richtig oder falsch scheinen sie sich in diese Richtung zu bewegen. EF entwickelt sich ständig weiter und bestimmte technische Einschränkungen werden aufgehoben, so dass EF letztendlich dazu benutzt werden kann, das Beste aus beiden Welten zu befriedigen. Mit anderen Worten, Sie können eventuell Ihren Kuchen essen und auch essen.

Hoffe das hilft.

Die Beantwortung einer Frage, ob das Ignorieren von Beharrlichkeit mit einem ORM oder nicht, ist lächerlich, wenn man bedenkt, dass der Zweck dahinter liegt, Daten zu verwalten. :-) Sorry, ich konnte nicht widerstehen!



Lizenziert unter: CC-BY-SA with attribution
Nicht verbunden mit Stack Overflow
Ist diese KB legal? Ja, lerne warum
Lizenziert unter: CC-BY-SA with attribution
Nicht verbunden mit Stack Overflow
Ist diese KB legal? Ja, lerne warum