DDD Model Design and Repository Persistenza Considerazioni sulle prestazioni

Question

DDD Model Design and Repository Persistenza Considerazioni sulle prestazioni

#1 da (2 voti)

2

Quindi ho letto di DDD per un po 'di tempo e ho cercato di capire l'approccio migliore su diversi argomenti.

Tendo ad essere d'accordo sul fatto che dovrei progettare il mio modello in modo persistente e agnostico. E quei repository dovrebbero caricare e mantenere i miei modelli in stati validi.

Ma questi approcci sono realistici praticamente? Intendo dire che è normale che un modello contenga un riferimento a una raccolta di un altro tipo. Persistendo quel modello dovrebbe significare che persiste l'intera collezione. Belle. Ma ho davvero bisogno di caricare l'intera collezione ogni volta che carico il modello? Probabilmente no.

Quindi posso avere repository specializzati. Alcuni che caricano forse un sottoinsieme del grafico dell'oggetto tramite DTO e altri che caricano l'intero grafico dell'oggetto. Ma quando posso usare quale? Se ho DTO, cosa impedisce al codice client di chiamarli direttamente e di ignorare completamente il modello?

Posso avere mapper e fabbriche per creare i miei modelli da DTOs forse? Ma a seconda del design dei miei modelli potrebbe non funzionare sempre. Oppure potrebbe non consentire la creazione dei miei modelli in uno stato valido.

MODIFICA 1: A parte il caricamento lazy / eager e l'utilizzo di un framework DI per iniettare repository nei miei modelli, qual è un altro approccio?

Qual è l'approccio corretto qui?

repository-pattern domain-driven-design performance domain-model

posta 9ee1 20.10.2012 - 19:11

fonte

1 risposta

Leggi altre domande sui tag repository-pattern domain-driven-design performance domain-model

GitHub OS project come avere una buona versione e una versione work in progress Objective C style nil in java?

score 2 · Answer 1

In primo luogo, è difficile avere sia un modello complesso che buone prestazioni. Questo è un compromesso che devi fare. Per avere entrambi, avresti bisogno di un investimento molto più grande della somma di entrambi. Se hai davvero bisogno di prestazioni, DDD non è una buona alternativa.

In secondo luogo, ti preoccupi delle prestazioni prima di scrivere effettivamente il codice e di delinearlo. Forse le implicazioni sul rendimento non sono così brutte come pensi e puoi facilmente usare l'approccio object-access / ORM / lazy senza problemi.

Ma se scopri, attraverso la creazione di profili, che le prestazioni sono negative, forse perché stai colpendo DB troppo spesso. La soluzione è probabilmente proprio come hai detto tu: metodi specializzati sui repository. Questi possono restituire entità insieme ad alcune entità correlate già richieste (caricamento ansioso tramite ORM) o facendo una query, che restituisce dati aggregati o filtrati specifici. Inoltre, sembra esserci un po 'di confusione, i metodi e gli oggetti di repository restituiti fanno parte del modello, proprio come i repository a cui appartengono. Quindi "bypassare il modello" non ha senso qui. Devi solo tenere costantemente d'occhio le prestazioni e assicurarti che gli sviluppatori utilizzino i metodi corretti per ridurre la duplicazione del codice e sfruttare i metodi più efficienti.