Il repository DDD può modificare l'entità nel DB senza un oggetto entità?

Question

Il repository DDD può modificare l'entità nel DB senza un oggetto entità?

#1 da (1 voti)
#2 da (1 voti)

1

Dire che ho una radice aggregata Entity con alcuni flag che sono rappresentati da un oggetto incapsulato EntityFlags :

class Entity
{
    /** @var EntityFlags */
    private $flags;
    ...
}

Ho un repository per questa entità.

Il mio obiettivo è modificare i flag nel DB. Ci sono due modi in cui vedo:

Ottieni entità dal repository, modifica i flag come $entity->getFlags()->set($name, true) e salvalo: $repository->save($entity) .
Creare un metodo aggiuntivo nel repository, ad es. %codice%

Penso che il primo modo sia ridondante. Ma sembra anche sbagliato usare il repository per aggiornamenti di entità parziali come nel 2 ° modo. Quale è quella giusta? Forse mi sono perso qualcosa?

domain-driven-design object-oriented-design

posta Vitaly Chirkov 18.04.2014 - 11:56

fonte

2 risposte

1

Entrambi sono possibili, ma la domanda è perché vorresti usarne uno rispetto all'altro. Il primo caso ti consente di fare del lavoro aggiuntivo quando imposti i flag. Forse vuoi modificare qualcos'altro o notificare altro pezzo di codice. Ciò è particolarmente vero per le radici aggregate, la cui ragione di esistenza è principalmente quella di garantire regole aziendali su più entità. Ma estrarre l'intera entità dal database, solo per cambiare la singola proprietà, sembra inutile. Il secondo caso rimuove questo spreco, ma rimuove anche la possibilità di eseguire qualsiasi regola aziendale durante la modifica. Inoltre, eventuali ottimizzazioni delle prestazioni devono essere precedute dalla profilazione, in modo da non complicare il codice per il guadagno di prestazioni "percepito".

Se fosse su di me, userei la prima opzione, e se capisco attraverso il profiling questo è un problema di prestazioni, lo cambierei in seconda opzione.

risposta data 18.04.2014 - 16:26

fonte

Leggi altre domande sui tag domain-driven-design object-oriented-design

Progettazione di tabelle per la registrazione di round in una partita Il visitatore è applicabile solo quando si utilizza il pattern Composite?

score 1 · Accepted Answer

Stai mettendo troppa responsabilità nel Deposito qui, allontanandoti dal modello originale. Un repository dovrebbe essere un insieme concettuale di oggetti di dominio, una raccolta da cui è possibile eseguire query o aggiunte senza preoccuparsi della memoria persistente sottostante.

modifyFlags(EntityId $id, EntityFlags $flags) potrebbe in genere essere la firma di un caso d'uso, vale a dire un metodo in uno dei servizi del livello applicazione, ma non un metodo repository. Un repository non dovrebbe contenere la logica di modifica dell'oggetto.

save($entity) potrebbe anche non adattarsi molto bene al repository, perché sapere come svuotare le cose nel database è una responsabilità separata in sé. L'API Unità di lavoro nella maggior parte degli strumenti di mappatura relazionale degli oggetti consente in genere di farlo. Non ha molto senso avere un metodo Save(object) su un array o un tipo di raccolta - allo stesso modo su un repository.