L'ID di entità come argomento costruttore o tramite un metodo setter?

Question

Quando si ha un'entità, come UserEntity, la proprietà id deriva dalla sua chiave primaria nel db - si dovrebbe fornire un metodo setter come setId()?

Alcuni argomenti contro:

• apre la porta a possibili sovrascritture accidentali di altre UserEntities nel db
• due (o più) UserEntities potrebbero esistere in qualsiasi momento con le stesse id ma diverse proprietà . (Se ho tirato 3 diversi utenti dal db e impostare i loro valori id allo stesso)

Alcuni argomenti di:

• se non ho per istanziare l'UserEntity con una id nel costruttore (dato che ha un metodo setter), posso usare i metodi dell'oggetto UserEntity con valori temporanei/falsi/nuovi utenti ... senza doverli prima persistere.

Fornire un setter (e non forzare un id nel costruttore), o forzare un id nel costruttore, e rimuovere il setter?

Answer 1

Il valore dell'identità di un'entità deve essere gestito dal livello di persistenza e idealmente non sarebbe impostabile da altro: il livello di persistenza dovrebbe assegnare un nuovo valore di identità alla persistenza e impostarlo al momento del recupero. Inoltre, dovresti essere in grado di utilizzare un'entità transitoria (non persistente) senza bisogno di accedere alla sua identità. Consentire all'identità di essere impostata tramite la funzione di costruzione può causare problemi perché non esiste una fonte autorevole per i valori di identità. Un esempio in cui le identità possono essere assegnate da fonti esterne è se un client richiede che un'entità di nuova persistenza abbia un valore UUID come identità, sebbene questo esempio sia forzato.

Answer 2

@johnnietheblack, preferisco creare un setter privato e getter pubblico agli ID entità. Le convalide saranno lì nel setter (se necessario) e ho impostato questo ID esclusivamente nei costruttori. Gli ID numerici vengono istanziati con valori zero che mi aiutano a monitorare il loro ciclo di vita.

Domain Driven Design di Eric Evans parla di domini di modelli quando Patterns of Enterprise Application Architecture di Martin Fowler approfondisce l'infrastruttura di queste applicazioni. Credo che siano complementari e lo raccomando.