Ho appena iniziato a leggere DDD. Non sono in grado di cogliere completamente il concetto di oggetti Entity vs Value .. Qualcuno può spiegare i problemi (manutenibilità, prestazioni .. ecc.) Che un sistema potrebbe incontrare quando un oggetto Value è progettato come un oggetto Entity? L'esempio sarebbe fantastico ...
Risposte:
Ridotta alla distinzione essenziale, l'identità conta per le entità, ma non importa per gli oggetti di valore. Ad esempio, il nome di qualcuno è un oggetto valore. Un'entità cliente potrebbe essere composta da un nome cliente (oggetto valore), List <Order> OrderHistory (elenco di entità) e forse un indirizzo predefinito (in genere un oggetto valore). L'entità cliente avrebbe un ID e ogni ordine avrebbe un ID, ma un nome no; generalmente, comunque all'interno del modello a oggetti, l'identità di un indirizzo probabilmente non ha importanza.
Gli oggetti valore possono essere tipicamente rappresentati come oggetti immutabili; cambiare una proprietà di un oggetto valore distrugge essenzialmente il vecchio oggetto e ne crea uno nuovo, perché non sei interessato all'identità quanto al contenuto. Correttamente, il metodo di istanza Equals su Name restituirebbe "true" fintanto che le proprietà dell'oggetto sono identiche a quelle di un'altra istanza.
Tuttavia, la modifica di alcuni attributi di un'entità come Customer non distrugge il cliente; un'entità cliente è tipicamente mutabile. L'identità rimane la stessa (almeno una volta che l'oggetto è stato mantenuto).
Probabilmente crei oggetti di valore senza rendertene conto; ogni volta che rappresenti un aspetto di un'entità creando una classe a grana fine, hai un oggetto valore. Ad esempio, una classe IPAddress, che ha alcuni vincoli su valori validi ma è composta da tipi di dati più semplici, sarebbe un oggetto valore. Un EmailAddress potrebbe essere una stringa o un oggetto valore con il proprio insieme di comportamenti.
È del tutto possibile che anche gli elementi che hanno un'identità nel tuo database non abbiano un'identità nel tuo modello a oggetti. Ma il caso più semplice è un composto di alcuni attributi che hanno senso insieme. Probabilmente non vuoi avere Customer.FirstName, Customer.LastName, Customer.MiddleInitial e Customer.Title quando puoi comporli insieme come Customer.Name; probabilmente saranno più campi nel tuo database nel momento in cui pensi alla persistenza, ma al tuo modello a oggetti non interessa.
int[1]può essere un valore mutabile non condiviso, un valore immutabile condivisibile (se nessuna delle cose che contengono riferimenti scriverà mai su di esso), o un'entità (se esistono due o più riferimenti, e uno di essi può essere usato per scrivere valori che possono essere letti utilizzando l'altro). Sfortunatamente, non conosco alcun supporto linguistico in Java o .NET per impedire agli oggetti di classe che incapsulano valori mutabili di trasformarsi accidentalmente in entità.
Qualsiasi oggetto che è definito collettivamente da tutti i suoi attributi è un oggetto valore. Se uno qualsiasi degli attributi cambia, hai una nuova istanza di un oggetto valore. Questo è il motivo per cui gli oggetti valore sono definiti immutabili.
Se l'oggetto non è completamente definito da tutti i suoi attributi, esiste un sottoinsieme di attributi che costituiscono l'identità dell'oggetto. Gli attributi rimanenti possono cambiare senza ridefinire l'oggetto. Questo tipo di oggetto non può essere definito come immutabile.
Un modo più semplice per fare la distinzione è pensare agli oggetti valore come dati statici che non cambieranno mai e alle entità come dati che si evolvono nell'applicazione.
Tipi di valore:
Entità:
Non so se quanto segue sia corretto, ma direi che nel caso di un oggetto Indirizzo, vogliamo usarlo come oggetto valore anziché come entità perché le modifiche all'entità si rifletterebbero su tutti gli oggetti collegati ( una persona per esempio).
Prendi questo caso: vivi a casa tua con altre persone. Se usassimo Entity for Address, direi che ci sarebbe un indirizzo univoco a cui si collegano tutti gli oggetti Person. Se una persona si trasferisce, aggiorna il suo indirizzo. Se aggiorni le proprietà dell'entità indirizzo, tutte le persone avrebbero un indirizzo diverso. Nel caso di un oggetto valore, non saremmo in grado di modificare l'indirizzo (poiché è immutabile) e saremmo costretti a fornire un nuovo indirizzo per quella persona.
Suona bene? Devo dire che ero / sono anche ancora confuso su questa differenza, dopo aver letto il libro DDD.
Andando oltre, come sarebbe modellato questo nel database? Avresti tutte le proprietà dell'oggetto Address come colonne nella tabella Person o creeresti una tabella Address separata che avrebbe anche un identificatore univoco? In quest'ultimo caso, le persone che vivono nella stessa casa avrebbero ciascuna un'istanza diversa di un oggetto Indirizzo, ma quegli oggetti sarebbero gli stessi tranne che per la loro proprietà ID.
indirizzo può essere entità o oggetto valore che dipende dal processo occupato. L'oggetto indirizzo può essere un'entità nell'applicazione del servizio di corriere, ma l'indirizzo può essere un oggetto valore in qualche altra applicazione. nell'applicazione del corriere l'identità è importante per l'oggetto indirizzo
Ho chiesto informazioni su questo in un altro thread e penso di essere ancora confuso. Potrei confondere le considerazioni sulle prestazioni con la modellazione dei dati. Nella nostra applicazione di catalogazione, un cliente non cambia fino a quando non è necessario. Sembra stupido, ma le "letture" dei dati dei clienti superano di gran lunga le "scritture" e poiché molte richieste Web stanno tutte colpendo il "set attivo" di oggetti, non voglio continuare a caricare i clienti più e più volte. Quindi stavo percorrendo una strada immutabile per l'oggetto Cliente: caricarlo, memorizzarlo nella cache e servire lo stesso al 99% delle richieste (multi-thread) che vogliono vedere il cliente. Quindi, quando un cliente cambia qualcosa, chiedi a un "editor" di creare un nuovo cliente e invalidare quello vecchio.
La mia preoccupazione è se molti thread vedono lo stesso oggetto cliente ed è mutabile, quindi quando un thread inizia a cambiare, ne deriva il caos negli altri.
I miei problemi ora sono: 1) è ragionevole e 2) il modo migliore per farlo senza duplicare molto codice sulle proprietà.
3 distinzione tra EntitieseValue Objects
Identificatore vs uguaglianza strutturale: le entità hanno un identificatore, le entità sono le stesse se hanno lo stesso identificatore. Gli oggetti valore oltre la mano hanno uguaglianza strutturale, consideriamo due oggetti valore uguali quando tutti i campi sono uguali. Gli oggetti valore non possono avere un identificatore.
Mutabilità vs immutabilità: gli oggetti valore sono strutture di dati immutabili mentre le entità cambiano durante la loro vita.
Durata: gli oggetti valore devono appartenere a entità
In una frase molto semplice posso dire, abbiamo tre tipi di uguaglianza:
L'uguaglianza dell'identificatore si riferisce solo all'entità e l'uguaglianza strutturale si riferisce solo all'oggetto valore. Infatti gli oggetti valore non hanno id e possiamo usarli in modo intercambiabile. anche gli oggetti valore devono essere immutabili e le entità possono essere modificabili e gli oggetti valore non avranno anzi una tabella nel database.