Schema del repository con caricamento lazying tramite POCO

Question

Sono in procinto di iniziare un nuovo progetto e creare gli oggetti business e l'accesso ai dati, ecc. Sto solo usando semplici vecchi oggetti clr piuttosto che qualsiasi orms. Ho creato due librerie di classi: 1) Business Objects: contiene tutti i miei oggetti business, tutti questi oggetti sono leggeri con solo proprietà e regole aziendali. 2) Repository - questo è per tutti i miei dati di accesso.

La maggior parte dei miei oggetti avrà una lista di bambini in e la mia domanda è qual è il modo migliore per caricare pigro questi valori in quanto non voglio riportare informazioni non necessarie se non ne ho bisogno.

Ho pensato di utilizzare "get" sulla proprietà child per verificare se il suo "null" e se è chiamare il mio repository per ottenere le informazioni del bambino. Questo ha due problemi da quello che posso vedere: 1) L'oggetto "sa" come ottenere se stesso preferirei che non ci fosse alcuna logica di accesso ai dati nell'oggetto. 2) Ciò richiedeva che entrambe le classi si riferissero reciprocamente e che in Visual Studio genera un errore di dipendenza circolare.

Qualcuno ha qualche suggerimento su come superare questo problema o eventuali raccomandazioni sul layout del mio progetto e dove può essere migliorato?

Grazie

Answer 1

Dopo aver esaminato le risposte fornite e ulteriori ricerche ho trovato un articolo che utilizza i delegati per il caricamento lazy. Ciò ha fornito una soluzione più semplice rispetto all'utilizzo di proxy o all'implementazione di NHibernate.

Ecco lo link per l'articolo.

Answer 2

È possibile aggirare il problema dipendenza circolare se il codice lazy loading carica il repository in fase di esecuzione (Activator.CreateInstance o qualcosa di simile) e quindi chiama il metodo appropriato attraverso la riflessione. Naturalmente ci sono delle penalità legate alle prestazioni associate alla riflessione, ma spesso risultano insignificanti nella maggior parte delle soluzioni.

Un altro modo per risolvere questo problema è compilare semplicemente una singola DLL, in questo caso è possibile separare logicamente i livelli utilizzando diversi spazi dei nomi e organizzare le classi utilizzando directory diverse.

Answer 3

Per fare ciò è necessario programmare le interfacce (astrazioni rispetto alle implementazioni) e/o dichiarare le proprietà virtuali. Quindi il repository restituisce un oggetto proxy per quelle proprietà che devono essere caricate pigramente. La classe che chiama il repository non è la più saggia, ma quando tenta di accedere a una di queste proprietà, il proxy chiama il database e carica i valori.

Francamente, penso che sia una follia cercare di implementare questo. Esistono soluzioni valide e collaudate per risolvere questo problema, che sono state sviluppate e perfezionate dalle migliori menti di .NET.

Per eseguire il proxy, è possibile utilizzare Castle DynamicProxy oppure è possibile utilizzare NHibernate e lasciare che gestisca tutto il carico di proxy e lazy per l'utente (utilizza DynamicProxy). Otterrai prestazioni migliori rispetto a qualsiasi implementazione a mano, garantita.

NHibernate non farà confusione con i tuoi POCO - nessun attributo, nessuna classe di base; è sufficiente contrassegnare i membri virtuali per consentire la generazione di proxy.

In poche parole, riconsidererei l'utilizzo di un ORM, soprattutto se si desidera un caricamento lento; non devi rinunciare ai tuoi POCO.

Answer 4

Se si utilizza Entity Framework 4.0, si avrà il supporto per POCO con caricamento differito & consentirà di scrivere un repository generico per l'accesso ai dati.

Ci sono tonnellate di articoli online sul modello di repository generico con EF 4.0

HTH.