Kann jemand diese 3 Konzepte und die Unterschiede zwischen ihnen in Bezug auf ein MVC-Framework zusammen mit einem Beispiel erklären. Für mich erscheinen diese fast gleichwertig, und es scheint, dass sie in einigen Artikeln austauschbar verwendet werden und nicht in anderen.Unterscheidung zwischen Domäne, Modell und Entität in Bezug auf MVC
Die Begriffe sind ein bisschen vage stimme ich zu. Ich würde Domäne verwenden, um auf den Geschäftsbereich zu verweisen, den Sie beschäftigen. Wie Bank oder Versicherung oder was nicht. Dann haben Sie Domain-Modelle. Dies sind die Dinge, mit denen Sie in dieser Geschäftsdomäne umgehen, wie für Domäne des Bankwesens haben Sie Konten, Kunden, Transfers usw. Ich würde Begriff Einheit für die Referenzierung der Klasse/POJO oder die persistente/konkrete Version eines Modells verwenden .
wahrscheinlich Was Sie hier verwirrt ist, dass in dem Begriff MVC, das Modell eine konkrete Sache, aber es das Datenmodell verweist verwendete irgendeine Darstellung in einem Web-GUI repräsentieren so nicht bekommen, dass der Misch in mit der obigen Erklärung.
Die Begriffe, über die Sie verwirrt sind, sind: "domain objects", "Domäneneinheiten" und "Modellobjekte". Obwohl Domain-Entities und Model-Objects normalerweise synonym verwendet werden, können sie auch Instanzen von active record Pattern sein (im Grunde: Domain-Objekte mit zusätzlicher Speicherlogik).
Im normalen Domänenobjekt gibt es keine Speicherlogik. Es wird von data mappers behandelt.
Der Begriff "Modellobjekte" kommt aus Fowlers Büchern (lesen Sie PoEAA für weitere Details), und, IMHO, ist ein Teil der Verwirrungen MVC, weil das gesamte Modell eine Anwendungsebene ist (MVC besteht aus ihm und Präsentationsebene) , die diese "Modellobjekte" enthält, die normalerweise von services behandelt werden (in diesem Bild ist die Modellschicht alle drei konzentrischen Kreise zusammen).
Ich bevorzuge viel lieber "Domain-Objekt" Begriff stattdessen.
Der Begriff "Domänenentität" (oder "Entitätsobjekt") wird normalerweise verwendet, wenn der Autor impliziert, dass das Objekt eine direkte Repräsentation einer Speicherstruktur ist (häufiger - eine Datenbanktabelle). Dies sind auch fast immer Implementierungen von Active Record.
P. S .: in einigen Artikeln würden Sie auch Begriff "Modelle" (Plural) sehen. Es ist normalerweise nicht direkt mit MVC-Entwurfsmustern verwandt, da es sich um eine Rails-artige Architektur handelt, bei der "Modelle" nur aktive Datensätze sind, die vom Controller direkt bereitgestellt/erstellt werden.
.. nicht sicher, ob diese Sie mehr verwirrt
Für die Aufzeichnung. In der Praxis sind Domäne und Modell identisch, während Entität auch eine Domäne/ein Objekt ist, das zum Speichern in der Datenbank verwendet wird.
Einige Leute werden versucht, solche Themen zu erklären, aber keiner von ihnen ist Kanon. Der Unterschied ist, dass in der Welt von Java Domain mehr verwendet wird, während in der Welt von C# Model verwendet wird (und MS ermutigt seine Verwendung), aber seine gerechte Konvention und Sie können beide verwenden.
In der gleichen, Konzept, Value Object (VO) wird von den Menschen von Java verwendet, während DTO für die Menschen von C#, auch wenn beide praktisch gleich sind. Auch POJO (Java) vs POCO (C#), Pakete (Java) vs NameSpace (C#), Setter und Getter (Java) vs Verkapselung (C#)
Beide Domänen und Modelle sind Klassen. Wie die Klasse verwendet wird, unterscheidet sich, wenn sie klassifiziert und in einen Domänen- oder Modellordner gestellt werden soll. Wenn die Klasse NUR in der Ansicht verwendet wird, legen Sie sie in den Modellordner. Wenn die Klasse einem Datenbankobjekt zugeordnet ist, fügen Sie sie in den Domänenordner ein.
Man könnte sagen, eine Domain sind die Klassen für die Datenbanktabellen, externe Serviceobjekte usw. Wenn Sie also ein Projekt entwickeln und ein Verzeichnis Domain erstellen, legen Sie die Datenbankobjekte darin ab. Eine solche Klasse ist eine Entität und kann mit ihren Eigenschaften eine Customer-Klasse sein. Warum ist das eine Entität und kein POCO? Das ist wegen seiner Verwendung. Der Inhalt der Entity kann in die Datenbank gelesen/geschrieben werden. Weil Sie es als eine Einheit betrachten, wissen Sie, wo Sie es verwenden können. Durch Wissen, Sie wissen, es ist eine Entität, Sie geben es nicht in seinem Namen. Jetzt zum Modell. Wenn Sie diesen Kunden verwenden, können Eigenschaften verwendet werden, die Sie nicht verwenden möchten. Ein Kunde kann eine wirklich einfache Entität sein. Aber sagen wir, Sie haben eine komplexe. Eine, die Sie von einem Web-Service mit so vielen Eigenschaften lesen, die Sie nicht verwenden. Dann können Sie diese Entity lesen (= kann perfekt mit der Serialisierung gemacht werden) und diese Entity verwenden, um ein Modell davon zu erstellen. Wenn diese Entity zum Kopieren von Daten in das Model verwendet wird, sprechen wir auch von einem Data Transformation Object (DTO), manchmal schreiben Sie dies als CustomerDTO. Um die Daten von der Entity in ein Model zu kopieren, können Sie Mapping-Tools verwenden. Der Name der Entität ändert sich dann zu CustomerModel. Dann verwenden Sie das Extension-Modell, weil Sie sonst nicht wissen, was was ist. In diesem CustomerModel kann es viele andere Eigenschaften geben. Einige dieser Eigenschaften können Prozesseigenschaften sein (sie müssen nicht von der Customer-Entität stammen). Der Inhalt dieser Eigenschaften stammt von anderen Diensten. Eine einfache Möglichkeit, die vom Kunden erstellt werden kann, ist Fullname, der aus mehreren Eigenschaften des Kunden besteht. Das Füllen eines CustomerModels kann daher komplex sein. Wir können den Code zum Füllen des CustomerModels in eine so genannte Factory schreiben und diese CustomerFactory aufrufen.