it-swarm.it

Oggetti Value vs Entity (Domain Driven Design)

Ho appena iniziato a leggere DDD. Non riesco a cogliere completamente il concetto di oggetti Entità vs Valore. Qualcuno può spiegare i problemi (manutenibilità, prestazioni, ecc.) Che un sistema potrebbe affrontare quando un oggetto Valore è progettato come oggetto Entity? L'esempio sarebbe grandioso ...

79
StackUnderflow

Ridotto alla distinzione essenziale, l'identità è importante per le entità, ma non ha importanza per gli oggetti valore. Ad esempio, il nome di qualcuno è un oggetto valore. Un'entità Cliente può essere composta da un Nome cliente (oggetto valore), Elenco <Ordine> 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 non dovrebbe; generalmente, 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 in sostanza distrugge il vecchio oggetto e ne crea uno nuovo, perché non sei interessato all'identità come al contenuto. Correttamente, il metodo di istanza Equals su Name restituirebbe "true" a condizione che le proprietà dell'oggetto siano identiche alle proprietà di un'altra istanza.

Tuttavia, la modifica di alcuni attributi di un'entità come il Cliente non distrugge il cliente; un'entità cliente è in genere mutabile. L'identità rimane la stessa (almeno una volta che l'oggetto è stato mantenuto).

Probabilmente crei oggetti valore senza rendertene conto; ogni volta che rappresenti alcuni aspetti di un'entità creando una classe a grana fine, hai un oggetto valore. Ad esempio, un IPAddress di classe, che ha alcuni vincoli sui valori validi ma è composto da tipi di dati più semplici, sarebbe un oggetto valore. Un EmailAddress potrebbe essere una stringa, oppure potrebbe essere un oggetto valore con il proprio insieme di comportamenti.

È possibile che anche gli oggetti che hanno un'identità nel database non abbiano un'identità nel modello a oggetti. Ma il caso più semplice è un insieme di alcuni attributi che hanno un senso insieme. Probabilmente non si desidera avere Customer.FirstName, Customer.LastName, Customer.MiddleInitial e Customer.Title quando è possibile comporli insieme come Customer.Name; probabilmente saranno più campi nel tuo database nel momento in cui pensi alla persistenza, ma al tuo modello di oggetto non interessa.

91
JasonTrue

Qualsiasi oggetto che è collettivamente definito da tutti gli 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 come immutabili.

Se l'oggetto non è completamente definito da tutti i suoi attributi, allora 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 immutabile.

Un modo più semplice per distinguere è pensare a oggetti di valore come dati statici che non cambieranno mai e entità come dati che evolvono nell'applicazione.

30
Richard Dorman

Non so se quanto segue è corretto, ma direi che nel caso di un oggetto Address, vogliamo usarlo come oggetto valore invece di un'entità perché le modifiche all'entità si rifletteranno su tutti gli oggetti collegati ( una persona per esempio).

Prendi questo caso: stai vivendo nella tua casa con altre persone. Se usassimo Entity for Address, direi che ci sarebbe un indirizzo univoco a cui tutti gli oggetti Person si collegano. Se una persona esce, vuoi aggiornare il suo indirizzo. Se si aggiornassero 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 un passo avanti, come sarebbe modellato nel database? Avresti tutte le proprietà dell'oggetto Address come colonne nella tabella Persona 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 Address, ma quegli oggetti sarebbero gli stessi ad eccezione della loro proprietà ID.

6

l'indirizzo può essere entità o valore oggetto che dipende dal processo di business. l'oggetto indirizzo può essere entità nell'applicazione del servizio di corriere, ma l'indirizzo può essere oggetto valore in qualche altra applicazione. nell'identità dell'applicazione di corriere vale per l'oggetto indirizzo 

3
Dharmesh

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 dal momento che molte richieste Web colpiscono tutti il ​​"set attivo" di oggetti, non voglio continuare a caricare i clienti più e più volte. Quindi mi sono diretto verso una strada immutabile per l'oggetto Cliente: caricarlo, archiviarlo in cache e servire lo stesso al 99% delle richieste (multi-thread) che desiderano vedere il Cliente. Quindi, quando un cliente cambia qualcosa, ottieni un 'editor' per creare un nuovo cliente e invalidare quello vecchio.

La mia preoccupazione è che se molti thread vedono lo stesso oggetto cliente ed è mutabile, allora quando un thread inizia a cambiare, può succedere qualcosa negli altri.

I miei problemi ora sono, 1) è ragionevole, e 2) il modo migliore per farlo senza duplicare molto codice sulle proprietà.

2
n8wrl

Tipi di valore:  

  • I tipi di valore non esistono da soli, dipendono dai tipi di Entità.
  • L'oggetto Type Type appartiene a un oggetto Type Entity.
  • La durata di vita di un'istanza di tipo valore è limitata dalla durata dell'istanza dell'entità proprietaria.
  • Tre tipi di valore: base (tipi di dati primitivi), composito (indirizzo) e raccolta (mappa, elenco, matrici)

Entità:  

  • I tipi di entità possono esistere da soli (identità)
  • Un'entità ha il proprio ciclo di vita. Può esistere indipendentemente da qualsiasi altra entità.
  • Ad esempio: Persona, Organizzazione, College, Mobile, Casa ecc. Ogni oggetto ha una sua identità
2
Premraj

3 distinzione tra Entities e Value Objects 

  • Identificatore vs uguaglianza strutturale: Le entità hanno identificatore, le entità sono le stesse se hanno lo stesso Identificatore . Valore Gli oggetti al di là della mano hanno uguaglianza strutturale, consideriamo due oggetti valore Uguali quando tutti i campi sono uguali. Gli oggetti valore non possono avere l'identificativo

  • Mutabilità vs immutabilità: Valore Gli oggetti sono strutture di dati immutabili mentre le entità cambiano durante Il loro tempo di vita.

  • Durata: gli oggetti valore dovrebbero appartenere alle entità

0
Ramin Farajpour