it-swarm-eu.dev

Objekte im Vergleich zu Objekten (domänengesteuertes Design)

Ich habe gerade angefangen, DDD zu lesen. Ich kann das Konzept der Entity vs. Value-Objekte nicht vollständig verstehen. Kann jemand die Probleme erklären (Wartbarkeit, Leistung usw.), denen ein System begegnen könnte, wenn ein Value-Objekt als Entity-Objekt entworfen wird? Beispiel wäre toll ...

79
StackUnderflow

Auf die wesentliche Unterscheidung reduziert, ist Identität für Entitäten von Belang, aber für Wertobjekte keine Rolle. Der Name einer Person ist beispielsweise ein Wertobjekt. Eine Kundenentität kann aus einem Kundennamen (Wertobjekt), List <Order> OrderHistory (Liste der Entitäten) und möglicherweise einer Standardadresse (normalerweise einem Wertobjekt) bestehen. Das Kundenunternehmen hätte eine ID, und jede Bestellung hätte eine ID, ein Name jedoch nicht. Im Allgemeinen ist die Identität einer Adresse im Objektmodell ohnehin unwichtig.

Wertobjekte können typischerweise 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 beschäftigen wie mit dem Inhalt. Die Equals-Instanzmethode für Name würde "true" zurückgeben, solange die Eigenschaften des Objekts mit den Eigenschaften einer anderen Instanz identisch sind.

Das Ändern eines Attributs einer Entität wie Customer zerstört den Kunden jedoch nicht. Eine Kundeneinheit ist normalerweise veränderbar. Die Identität bleibt gleich (zumindest wenn das Objekt persistent ist).

Sie erstellen wahrscheinlich 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. Beispielsweise wäre eine Klasse IPAddress, die gültige Werte einschränkt, aber aus einfacheren Datentypen besteht, ein Wertobjekt. Eine EmailAddress kann eine Zeichenfolge sein oder ein Wertobjekt mit einem eigenen Satz von Verhalten.

Es ist durchaus möglich, dass auch Elemente mit einer Identität in Ihrer Datenbank keine Identität in Ihrem Objektmodell haben. Der einfachste Fall besteht jedoch aus einer Kombination einiger Attribute, die zusammen einen Sinn ergeben. Sie möchten wahrscheinlich nicht Customer.FirstName, Customer.LastName, Customer.MiddleInitial und Customer.Title haben, wenn Sie diese als Customer.Name zusammenstellen können. Sie werden wahrscheinlich mehrere Felder in Ihrer Datenbank enthalten, wenn Sie über die Persistenz nachdenken, aber Ihr Objektmodell ist nicht von Belang.

91
JasonTrue

Jedes Objekt, das gemeinsam von allen it-Attributen definiert wird, ist ein Wertobjekt. Wenn sich eines der Attribute ändert, haben Sie eine neue Instanz eines Wertobjekts. Deshalb werden Wertobjekte als unveränderlich definiert.

Wenn das Objekt nicht durch alle seine Attribute vollständig 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 Art der Unterscheidung besteht darin, Wertobjekte als statische Daten zu betrachten, die sich niemals ändern, und Entitäten als Daten, die sich in Ihrer Anwendung entwickeln.

30
Richard Dorman

Ich weiß nicht, ob das Folgende korrekt ist, aber ich würde sagen, dass wir es im Fall eines Address-Objekts als Wertobjekt anstelle einer Entität verwenden möchten, da Änderungen an der Entität sich auf alle verknüpften Objekte auswirken würden ( eine Person zum Beispiel).

Nehmen Sie diesen Fall an: Sie wohnen in Ihrem Haus mit einigen anderen Menschen. Wenn wir Entity for Address verwenden würden, würde ich behaupten, dass es eine eindeutige Adresse gibt, zu der alle Personenobjekte verlinkt sind. Wenn eine Person ausgezogen ist, möchten Sie ihre Adresse aktualisieren. Wenn Sie die Eigenschaften der Adressentität aktualisieren, haben alle Personen eine andere Adresse. Im Falle eines Wertobjekts können wir die Adresse nicht bearbeiten (da sie unveränderlich ist), und wir müssten für diese Person eine neue Adresse angeben.

Klingt das richtig? Ich muss sagen, dass ich nach dem Lesen des DDD-Buchs auch immer noch verwirrt war.

Einen Schritt weiter gehen, wie würde dies in der Datenbank modelliert werden? Hätten Sie alle Eigenschaften des Adressobjekts als Spalten in der Personentabelle oder würden Sie eine separate Adressentabelle erstellen, die auch einen eindeutigen Bezeichner hätte? Im letzteren Fall haben die Personen, die im selben Haus leben, jeweils eine andere Instanz eines Address-Objekts, aber diese Objekte wären bis auf ihre ID-Eigenschaft gleich.

6

adresse kann ein Entity- oder Value-Objekt sein, das vom geschäftlichen Prozess abhängt. Das Adressobjekt kann eine Entität in der Kurierdienstanwendung sein, die Adresse kann jedoch ein Wertobjekt in einer anderen Anwendung sein. in Kurieranwendung Identitätsangelegenheiten für Adressobjekt 

3
Dharmesh

Ich habe in einem anderen Thread danach gefragt und ich denke, ich bin immer noch verwirrt. Ich kann die Leistungsaspekte mit der Datenmodellierung verwechseln. In unserer Katalogisierungsanwendung ändert sich ein Kunde erst, wenn dies erforderlich ist. Das klingt dumm - aber das Lesen von Kundendaten übertrifft bei weitem die Anzahl der Schreibvorgänge. Da viele Webanfragen alle auf den aktiven Satz von Objekten zutreffen, möchte ich Kunden nicht immer wieder laden. Ich ging also einen unveränderlichen Weg für das Kundenobjekt ein - laden Sie es, zwischenspeichern Sie es und stellen Sie es auf die 99% der (Multithreading-) Anforderungen, die den Kunden sehen möchten. Wenn ein Kunde etwas ändert, dann holen Sie sich einen 'Editor', um einen neuen Kunden zu erstellen, und machen Sie den alten ungültig.

Meine Sorge ist, wenn viele Threads dasselbe Kundenobjekt sehen und es sich veränderbar ist, wenn ein Thread anfängt, sich zu ändern, tritt in den anderen ein Chaos auf.

Meine Probleme sind jetzt: 1) Ist das vernünftig und 2) wie kann ich dies am besten tun, ohne viel Code über die Eigenschaften zu kopieren?.

2
n8wrl

Werttypen:  

  • Werttypen sind nicht allein vorhanden, abhängig von Entitätstypen.
  • Das Value Type-Objekt gehört zu einem Entity Type-Objekt.
  • Die Lebensdauer einer Werttypinstanz ist durch die Lebensdauer der besitzenden Entitätsinstanz begrenzt.
  • Drei Werttypen: Basis (primitive Datentypen), Composite (Adresse) und Collection (Karte, Liste, Arrays)

Entitäten:  

  • Entitätstypen können eigenständig existieren (Identität)
  • Eine Entität hat ihren eigenen Lebenszyklus. Sie kann unabhängig von anderen Entitäten bestehen.
  • Zum Beispiel: Person, Organisation, Hochschule, Mobil, Zuhause usw. Jedes Objekt hat seine eigene Identität
2
Premraj

3 Unterscheidung zwischen Entities und Value Objects 

  • Bezeichner vs. strukturelle Gleichheit: Entitäten haben einen Bezeichner. Entitäten sind gleich, wenn sie den gleichen Bezeichner . Wertobjekte auf der anderen Seite der Hand haben Die Felder sind gleich. Wertobjekte können nicht Einen Bezeichner haben.

  • Mutabilität versus Unveränderlichkeit: Value-Objekte sind unveränderliche Datenstrukturen, während Entitäten sich __ während ihrer Lebensdauer verändern.

  • Lebensdauer: Wertobjekte sollten zu Entitäten gehören

0
Ramin Farajpour