Classe di base astratta per tutti gli oggetti entità dominio

Question

Sto vedendo in alcuni modelli di oggetti di dominio che viene creata una classe base astratta (che implementa Equals e GetHashCode) per tutti gli oggetti Entity di dominio da ereditare per ottenere la propria identità.

Non sono chiaro perché questa classe di base sia necessaria e quando e perché debba essere utilizzata. Mi può fornire qualche informazione su questo o fare riferimento a me un link che parla su questo

Grazie

Ora capisco i vantaggi di override dei sessi (questo link aiutato http://en.csharp-online.net/CSharp_Canonical_Forms -Identity_Equality)

Tornando al dominio design guidato Vorrei ampliare un po 'la mia domanda;

Ho un'entità cliente che utilizzo guid come identità.

Se creo 2 istanze di cliente con esattamente gli stessi dettagli, dal momento che sto usando guid come identità saranno due oggetti diversi. Ma dato che hanno tutti gli attributi uguali dovrebbero essere lo stesso oggetto (o è una pratica migliore per mantenerli unici e separati ??)

Cercando di capire se dovrei gestire l'uguaglianza di due oggetti con il loro pieno valore attributo corrisponde. Se vado verso quella direzione, osservo l'override dell'uguaglianza della classe base sul livello della sottoclasse e implementare queste condizioni o l'identità dell'entità una stringa o codice hash (?) Rappresentazione dei valori di tutti questi attributi e utilizzare l'uguaglianza della classe base.

Potrei essere un po 'qui, quindi grazie in anticipo per la pazienza.

Answer 1

L'uso del termine uguaglianza è sovraccarico qui:

1) uguaglianza per Identità

Se avete 2 istanze dello stesso cliente, entrambi dovrebbero avere lo stesso valore GUID - è l'unico modo per garantire che si sta lavorando con la stessa entità. In realtà, ci saranno sempre diverse istanze della stessa Entità (ad esempio app multiutente in esecuzione su macchine diverse).

2) La parità di identità

Questo è dove si sta controllando che 2 casi hanno tutti gli stessi valori. Ad esempio, se 2 membri dello staff guardano lo stesso cliente e la prima persona modifica & lo salva, entrambe le persone vedranno dati diversi. Sono entrambi interessati allo stesso cliente, ma i dati diventano obsoleti.

Per (2), è assolutamente necessario un meccanismo per eseguire il controllo.È possibile confrontare ciascuna proprietà (costoso) oppure è possibile utilizzare una proprietà 'versione' per rilevare le modifiche (vedere NHibernate’s optimistic locking mechanism).

Penso che il tuo esempio sia un po 'artificioso e potrebbe trascinarti lontano dagli aspetti più importanti della DDD. Se sei interessato, I sell a tool che può aiutare a cogliere più facilmente i concetti di DDD.

Answer 2

Hai indicato due dei motivi per cui viene utilizzato.

Per Uguali non si può voler controllare sempre se il riferimento reale è uguale, perché potrebbe non esserlo. Si consiglia di utilizzare una sorta di proprietà di identificazione (come ID int pubblico) per verificare se 2 entità sono uguali. L'implementazione di base di Equals sta andando a verificare se i 2 riferimenti sono uguali.

Per quanto codice hash è un modo per identificare in modo univoco un determinato oggetto/tipo quando viene utilizzato in algoritmi hash ecc

Answer 3

Sarebbe equo controllare solo l'identità, perché consente di avere un'istanza di un'entità contenente una situazione precedente e successiva, che può essere molto utile a volte. Per verificare se un'istanza è cambiata, una bandiera sporca può fare il trucco.

HTH, Jonathan

Answer 4

Se si sta seguendo DDD, credo che si dovrebbe verificare sull'uguaglianza degli oggetti dal loro ID (Identità). Questo perché le entità di dominio sono definite e monitorate primariamente dalla sua identità e non dagli attributi. Quindi, per quanto simili siano con altri oggetti, sono ancora entità diffirenti.

Un altro concetto che si desidera verificare è un oggetto valore. È qualcosa che descrive una caratteristica di un oggetto e non richiede un'identità. Esempio sarebbe, indirizzo, denaro, colore.

Answer 5

È necessario confrontare gli ID degli oggetti se sono entità e i relativi attributi nel caso in cui siano oggetti valore. Ciò significa che non devi ereditare gli oggetti valore da un'entità di base, ma per le entità è meglio crearne uno.

Come capire se una classe è un'entità o un oggetto valore? Dovresti rispondere a una domanda: gli oggetti di tale classe sono uguali se hanno lo stesso attributo impostato? Se sì, sono oggetti valori. Ad esempio, due persone non sono uguali anche se hanno gli stessi nomi e date di nascita - dovresti trattarle comunque come entità differenti. Ma se hai una moneta da 25 cent, probabilmente non ti interessa quale pezzo di metallo esatto hai, tutti solo monete da 25 cent.

C'è un grande articolo che descrive i dettagli: domain object base class