Ich habe gerade angefangen zu lesen DDD. Ich bin nicht in der Lage, das Konzept von Entity vs Value-Objekten vollständig zu verstehen. Kann jemand bitte die Probleme (Wartbarkeit, Leistung, etc.) erklären, denen ein System begegnen könnte, wenn ein Value-Objekt als Entity-Objekt entworfen wird? Beispiel wäre toll ...Wert vs Entity Objekte (Domain Driven Design)
Auf den wesentlichen Unterschied reduziert, ist Identität für Entitäten von Bedeutung, spielt aber für Wertobjekte keine Rolle. Zum Beispiel ist jemandes Name ein Wertobjekt. Eine Kundenentität könnte aus einem Kundennamen (Wertobjekt), Liste <Auftrag> OrderHistory (Liste von Entitäten) und möglicherweise einer Standardadresse (normalerweise ein Wertobjekt) bestehen. Die Kundeneinheit hätte eine ID, und jede Bestellung hätte eine ID, aber ein Name sollte nicht; Im Allgemeinen spielt innerhalb des Objektmodells die Identität einer Adresse wahrscheinlich keine Rolle.
Wertobjekte können normalerweise als unveränderliche Objekte dargestellt werden; Wenn Sie eine Eigenschaft eines Wertobjekts ändern, wird das alte Objekt im Wesentlichen zerstört und ein neues erstellt, da Sie sich nicht so sehr mit der Identität als mit dem Inhalt beschäftigen. Die Equals-Instanzmethode für Name würde richtigerweise "true" zurückgeben, solange die Objekteigenschaften mit den Eigenschaften einer anderen Instanz identisch sind.
Wenn Sie jedoch ein Attribut einer Entität wie Customer ändern, wird der Kunde nicht zerstört. Eine Kundeneinheit ist normalerweise änderbar. Die Identität bleibt gleich (zumindest sobald das Objekt persistent ist).
Wahrscheinlich erstellen Sie Wertobjekte, ohne es zu merken. Immer wenn Sie einen Aspekt einer Entität darstellen, indem Sie eine feinkörnige Klasse erstellen, haben Sie ein Wertobjekt. Zum Beispiel wäre eine Klasse IPAddress, die einige Einschränkungen für gültige Werte hat, aber aus einfacheren Datentypen besteht, ein Wertobjekt. Eine EmailAddress könnte eine Zeichenfolge oder ein Wertobjekt mit einem eigenen Verhalten sein.
Es ist durchaus möglich, dass auch Objekte mit einer Identität in Ihrer Datenbank keine Identität in Ihrem Objektmodell haben. Der einfachste Fall ist jedoch eine Zusammensetzung einiger Attribute, die zusammen Sinn ergeben. Sie möchten wahrscheinlich Customer.FirstName, Customer.LastName, Customer.MiddleInitial und Customer.Title nicht haben, wenn Sie diese zusammen als Customer.Name erstellen können; Wenn Sie über Persistenz nachdenken, sind sie wahrscheinlich mehrere Felder in Ihrer Datenbank, aber Ihr Objektmodell ist nicht wichtig.
Wohin passen nicht freigegebene veränderbare Objekte? Wenn es im gesamten Universum nur einen Verweis auf ein Objekt gibt, ist die Identität des Objekts irrelevant, auch wenn es veränderbar ist. Wie ich es sehe, ist ein Ding eine Entität, wenn es eine Referenz gibt, die benutzt werden könnte, um einen Aspekt des Zustandes zu beobachten, der sich ändern könnte * ohne dass dieser Bezug verwendet wurde, um ihn zu ändern *. Wenn ein Ding sich nicht an die Außenwelt anheftet und es entweder unveränderlich ist oder nur eine Referenz irgendwo im Universum existiert, dann kann das obige Szenario nicht auftreten und es ist ein Wert. – supercat
Etwas wie ein 'int [1]' kann ein ungeteilter veränderbarer Wert sein, ein gemeinsam nutzbarer unveränderlicher Wert (wenn keines der Dinge, die Referenzen enthalten, jemals darauf schreiben) oder eine Entität (wenn zwei oder mehr Referenzen existieren, und eine von ihnen können verwendet werden, um Werte zu schreiben, die mit dem anderen gelesen werden können). Leider kenne ich keine Sprachunterstützung in Java oder .NET, um zu verhindern, dass Klassenobjekte, die veränderbare Werte enthalten, versehentlich in Entitäten umgewandelt werden. – supercat
@supercat, Wenn Sie keine direkte einfache Unterstützung meinen, stimme ich zu, aber ich mache das, indem ich den öffentlichen Zugriff auf Konstruktoren beseitige, nur statische Fabriken benutze, um neue Instanzen zu erstellen, und den Zugriff auf den Status durch schreibgeschützte Eigenschaften einschränke). –
Ich weiß nicht, ob das Folgende korrekt ist, aber ich würde sagen, dass wir im Fall eines Address-Objekts es als ein Value-Objekt anstelle einer Entität verwenden möchten, da Änderungen an der Entität widergespiegelt werden alle verknüpften Objekte (eine Person zum Beispiel).
Nehmen Sie diesen Fall: Sie leben in Ihrem Haus mit einigen anderen Menschen. Wenn wir Entität für Adresse verwenden würden, würde ich argumentieren, dass es eine eindeutige Adresse geben würde, auf die alle Personenobjekte verweisen. Wenn eine Person auszieht, möchten Sie ihre Adresse aktualisieren. Wenn Sie die Eigenschaften der Adresseinheit aktualisieren würden, hätten alle Personen eine andere Adresse. Im Falle eines Value-Objekts wären wir nicht in der Lage, die Adresse zu bearbeiten (da sie unveränderlich ist), und wir wären gezwungen, eine neue Adresse für diese Person anzugeben.
Klingt das richtig? Ich muss sagen, dass ich auch über diesen Unterschied verwirrt war, nachdem ich das DDD-Buch gelesen hatte.
Einen Schritt weiter gehen, wie würde dies in der Datenbank modelliert werden? Würden Sie alle Eigenschaften des Address-Objekts als Spalten in der Person-Tabelle haben oder würden Sie eine separate Adreßtabelle erstellen, die auch eine eindeutige Kennung hätte? Im letzteren Fall würden die Personen, die im selben Haus leben, jeweils eine andere Instanz eines Address-Objekts haben, aber diese Objekte wären bis auf ihre ID-Eigenschaft identisch.
"Nehmen Sie diesen Fall: Sie leben in Ihrem Haus mit einigen anderen Menschen. Wenn wir Entität für Adresse verwenden würden, würde ich argumentieren, dass es eine eindeutige Adresse geben würde, die alle Personenobjekte verknüpfen". Ich denke, jeder dieser Leute hat seine eigene Instanz von Address, aber sie sind zufällig gleich (es ist so, als ob jeder von ihnen eine 5-Dollar-Banknote haben könnte, aber das bedeutet nicht, dass es dieselbe Banknote ist) – Prokurors
Jedes Objekt, das gemeinsam von allen Attributen definiert wird, ist ein Wertobjekt. Wenn sich eines der Attribute ändert, haben Sie eine neue Instanz eines Wertobjekts. Aus diesem Grund sind Wertobjekte als unveränderlich definiert.
Wenn das Objekt nicht vollständig durch alle Attribute definiert ist, gibt es eine Teilmenge von Attributen, die die Identität des Objekts ausmachen. Die verbleibenden Attribute können sich ändern, ohne das Objekt neu zu definieren. Diese Art von Objekt kann nicht als unveränderlich definiert werden.
Eine einfachere Methode zur Unterscheidung besteht darin, Wertobjekte als statische Daten zu betrachten, die sich niemals ändern, und Entitäten als Daten, die sich in Ihrer Anwendung entwickeln.
Ich fragte darüber in einem anderen Thread und ich denke, ich bin immer noch verwirrt. Ich kann Leistungsüberlegungen mit der Datenmodellierung verwechseln. In unserer Katalogisierungsanwendung ändert sich ein Kunde erst, wenn es erforderlich ist. Das hört sich doof an - aber das 'Lesen' von Kundendaten ist den "Schreibvorgängen" bei weitem überlegen, und da viele Webanfragen alle auf das "aktive Set" von Objekten treffen, möchte ich Kunden nicht immer wieder aufladen. So ging ich eine unveränderliche Straße für das Objekt Customer - laden Sie es, zwischenspeichern Sie es und bieten Sie dasselbe an die 99% der (Multi-threaded) Anforderungen, die den Kunden sehen möchten. Wenn ein Kunde etwas ändert, rufen Sie einen "Editor" auf, um einen neuen Kunden zu erstellen und den alten Kunden ungültig zu machen.
Meine Sorge ist, wenn viele Threads das gleiche Kundenobjekt sehen und es veränderbar ist, dann, wenn ein Thread anfängt, sich zu ändern, entsteht Chaos in den anderen.
Meine Probleme sind jetzt, 1) ist das vernünftig, und 2), wie Sie dies am besten tun, ohne eine Menge Code über die Eigenschaften zu duplizieren.
Adresse kann Entitäts- oder Wertobjekt sein, das vom Busi- sess-Prozess abhängt. Adressobjekt kann Entität in Kurierdienstanwendung sein, aber Adresse kann Wertobjekt in einer anderen Anwendung sein. in Kurier Anwendungsidentität Angelegenheiten für Adreßobjekt
3 Unterscheidung zwischen Entities und Value Objects
Identifier vs Strukturgleichheit: Entities haben Kennung, sind Einheiten, die gleiche, wenn sie die gleiche Kennung. Wert Objekte auf jenseits der Hand haben strukturelle Gleichheit, wir betrachten zwei Wertobjekte gleich, wenn alle Felder gleich sind. Wertobjekte können keine Kennung haben. Mutability vs immutability: Wert Objekte sind unveränderliche Datenstrukturen, während Entitäten während ihre Lebensdauer ändern.
Lebensdauer: Wert Objekte sollten
Werttypen zu Entities gehören:
Instanzen:
Hier schrieb ich eine volle (IMO) Liste der Unterschiede zwischen den beiden: http: // enterprisecraftsmanship. com/2016/01/11/entity-vs-value-objekt-the-ultimate-list-of-differences/ – Vladimir