Sono oggetti persistenza ignoranti in grado di implementare il caricamento lazy?

Question

Sono oggetti persistenza ignoranti in grado di implementare il caricamento lazy?

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

12

Persistenza L'ignoranza è un'applicazione del principio della responsabilità unica, che in pratica significa che gli oggetti del dominio ( DO ) non dovrebbero contenere codice relativo alla persistenza, ma dovrebbero solo contenere la logica di dominio

a) Presumo questo significa che il codice che contatta i livelli inferiori (cioè i livelli di persistenza) vive al di fuori del modello di dominio in altre classi ( OC ) di un livello di business logic?

b) Se la mia ipotesi in a) è corretta, allora DO , ad esempio Customer , non contiene mai metodi come GetCustomers o GetCustomerByID ?

c) Se le mie ipotesi sotto a) e b) sono corrette, e supponendo che Customer oggetto di dominio usi il caricamento lazy per alcune delle sue proprietà, allora ad alcuni la logica interna di point Customer deve contattare OC , che a sua volta recupera i dati deffered. Ma se Customer ha bisogno di contattare OC per ricevere dati deffered, allora non possiamo davvero affermare che gli Oggetti Dominio non contengano logiche relative alla persistenza?!

Grazie

RISPOSTA A jkohlhepp

1) Presumo che OrderProvider e CustomerProvider siano contenute nel livello della logica aziendale?

2) Dalla tua risposta deduco che le mie ipotesi sotto b) sono corrette?

3)

... I would check to see if some private orders field was populated or if it was null. If it is null ...

Ma per quanto posso dire, non appena il codice del dominio deve verificare se il campo order privato è stato popolato, e se non lo è, contattando OrderProvider, stiamo già violando PI principio?!

domain-driven-design design-patterns domain-model persistence

posta user1483278 12.07.2012 - 20:48

fonte

2 risposte

2

Hai solo una classe di collegamento che popola gli oggetti del dominio (ad esempio, qualcosa chiamato "repository"). È possibile implementare il caricamento lazy o qualsiasi tipo di schema di coerenza della cache desiderato e gli oggetti del dominio non sono più saggi. Stai separando la responsabilità di popolare gli oggetti di dominio da oggetti di dominio.

risposta data 12.07.2012 - 21:11

fonte

Leggi altre domande sui tag domain-driven-design design-patterns domain-model persistence

Qual è la licenza software "predefinita"? Termine opposto del trattino [chiuso]

score 4 · Accepted Answer

Credo che tu abbia ragione nelle tue ipotesi A e B riguardo all'ignoranza della persistenza.

Il modo migliore per eseguire il caricamento lento degli oggetti del database dipende in gran parte dal problema e dall'implementazione specifici. Tuttavia, tenterò una risposta generica su come eseguire il caricamento lazy mantenendo comunque la separazione delle preoccupazioni tra le classi di persistenza e di logica del dominio.

Tendo ad attuare l'ignoranza della persistenza usando le seguenti classi:

Classi di dominio - ad es. Clienti
Classi provider / repository - ad es. CustomerProvider
Classi di query di database generiche, ad es. DatabaseQuery

La classe DatabaseQuery sarebbe responsabile dell'utilizzo del driver del database per interrogare il database e assemblare i dati risultanti in un set di risultati generico come un DataTable. Il CustomerProvider sarebbe responsabile dell'utilizzo della classe DatabaseQuery per eseguire SQL sul database e utilizzare i risultati di tale SQL per assemblare le istanze del cliente. Il cliente sarebbe un oggetto di dominio "puro" che conteneva dati e logica relativi ai clienti.

Per quanto riguarda il fatto che le classi dei provider debbano essere nel livello aziendale o nel livello dati, non ho un'opinione strong. Posso vedere un caso per entrambi. La parte importante è che si separano le responsabilità tra le classi.

Quindi ora parliamo di caricamento pigro. Diciamo che volevo che il Cliente avesse una raccolta di ordini, ma non voglio estrarre gli ordini dal database a meno che il consumatore non provi ad accedervi. Creerei una proprietà sul cliente chiamata ordini. Nel getter di quella proprietà, vorrei verificare se qualche campo di ordini privati fosse popolato o se fosse nullo. Se è nullo, caricare gli ordini dal database utilizzando OrderProvider. Altrimenti, restituisci la raccolta già caricata.

A mio parere, la necessità per il Cliente di contattare OrderProvider non non viola PI. Il cliente ancora non sa come riceve gli ordini. Sa solo che li ottiene da OrderProvider. Potrebbero esserci altri motivi per disaccoppiare il Cliente da OrderProvider, ma non penso che PI sia un problema qui.

Questo presuppone che tu stia facendo ignoranza di persistenza manualmente. Se si utilizza un framework ORM come Entity Framework o Hibernate, tali framework generalmente dispongono di funzionalità per supportare il caricamento lazy automagicamente.