Gli oggetti di persistenza-ignoranti sono in grado di implementare il caricamento lento?

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

a) Presumo che ciò significhi che il codice che contatta i livelli inferiori (ovvero i livelli di persistenza) vive al di fuori del modello di dominio in altre classi ( OC ) di un livello di logica aziendale?

b) Se la mia ipotesi in a) è corretta, allora DO , diciamo Customer, non contiene mai metodi come GetCustomerso GetCustomerByID?

c) Se le ipotesi sotto a) e b) sono corrette, e supponendo Customeroggetto dominio utilizza il caricamento pigro per alcune delle sue proprietà, poi ad un certo punto Customer's interno mosto logica contatto OC , che a sua volta recupera deffered dati. Ma se è Customernecessario contattare OC per ricevere dati non validi, non possiamo davvero affermare che gli oggetti di dominio non contengono una logica correlata alla persistenza ?!

Grazie

RISPOSTA A jkohlhepp

1) Presumo OrderProvidere le CustomerProviderclassi sono contenute nel livello di logica aziendale?

2) Capisco dalla tua risposta che i miei presupposti di cui alla lettera b) sono corretti?

3)

... Vorrei verificare se un campo di ordini privati ​​era popolato o se era nullo. Se è nullo ...

Ma per quanto ne so, non appena il codice di dominio deve verificare se il ordercampo privato è stato popolato e, in caso contrario, contattando OrderProvider, stiamo già violando il principio PI ?!

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

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

Tendo a implementare l'ignoranza della persistenza usando le seguenti classi:

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

La classe DatabaseQuery sarebbe responsabile dell'utilizzo del driver del database per eseguire una query sul database e assemblare i dati risultanti in un set di risultati generico come DataTable. 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 se le classi di provider dovrebbero essere nel livello aziendale o nel livello dati, non ho una forte opinione. Vedo un caso per entrambi. La parte importante è che si separano le responsabilità tra le classi.

Quindi ora parliamo di caricamento lento. Diciamo che volevo che il cliente avesse una raccolta di ordini, ma non desidero estrarre gli ordini dal database a meno che il consumatore non tenti di accedervi. Vorrei creare una proprietà sul cliente denominata Ordini. Nel getter di quella proprietà, vorrei verificare se un campo di ordini privati ​​era popolato o se era nullo. Se è null, caricare gli ordini dal database utilizzando un OrderProvider. Altrimenti, restituisci la raccolta già caricata.

A mio avviso, la necessità per il cliente di contattare OrderProvider non viola PI. Il cliente continua a non sapere come riceve gli ordini. Sa solo che li ottiene da OrderProvider. Potrebbero esserci altri motivi per disaccoppiare il cliente da OrderProvider, ma non credo che PI sia un problema qui.

Questo presuppone che stai facendo manualmente l'ignoranza sulla persistenza. Se si utilizza un framework ORM come Entity Framework o Hibernate, tali framework generalmente dispongono di funzionalità per supportare il caricamento lento in modo automatico.

Hai solo una classe wireup che popola gli oggetti di dominio (diciamo, qualcosa chiamato "repository"). È possibile implementare il caricamento lento 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 oggetti di dominio dall'essere oggetti di dominio.