Il pattern DAO è ampiamente utilizzato in .NET?

Question

L'oggetto di accesso ai dati DAO è uno schema comunemente utilizzato in .NET? Ho sempre utilizzato DAO come metodo per fornire l'accesso al mio livello dati. Ad esempio, potrei avere un'interfaccia sottile sul mio oggetto ObjectContext EntityFramework che espone tutti i miei ObjectSet come IObjectSet.

Le query complesse sarebbero quindi esposte dai DAO, ognuno dei quali con una dipendenza da questa interfaccia. Potrei avere un ProductDAO che espone metodi come GetProductsOnSale() o GetInfrequenlySoldProducts(). I miei controllori o relatori avrebbero quindi utilizzato questi metodi, che probabilmente sarebbero virtuali per consentire la stubing di risultati specifici per i test unitari.

Quindi questo è un linguaggio comunemente utilizzato in .NET? Per qualche motivo la stragrande maggioranza degli esempi che vedo online utilizzando questo modello sono basati su Java. Anche lo this question sulle best practice DAO è contrassegnato come Java e non C#.

Non c'è niente di sbagliato con l'utilizzo qualcosa da un'altra comunità, ho solo un leggero timore che tutti intorno a me sta facendo le cose in modo diverso ...

Answer 1

Si tratta di un idioma comune in .NET. L'ho usato e l'ho visto usato in molti posti.

E 'integrato nel framework - vedere lo spazio dei nomi System.Data - molte delle classi sono classi base per provider specializzati (SQL Server, Oracle, MySQL ecc.) E le operazioni vengono eseguite sulle classi base.

Tuttavia, quello che stai descrivendo suona più come lo Repository Pattern per me, non semplicemente per l'uso di Data Access Objects.

Questo è anche utilizzato in molti progetti, sebbene non sia integrato nel framework.

Answer 2

Uso estesamente il modello DAO.

Lei ha citato l'Entity Framework; a questo aggiungo che trovo DAO molto meglio di DataSet e DataTable, che sono troppo simili a un database e non sono abbastanza simile a un oggetto per i miei gusti. Ad esempio, DataRows non può essere aggiunto a più di una tabella di dati, quindi non posso passare sottoinsiemi dei dati caricati a oggetti diversi senza spostarli in un contenitore che non è stato creato per contenerli. (Ad esempio, sembra che DataRow debba essere incluso in un DataTable, ma possono essere solo in un DataTable alla volta.) DataRowViews sono goffi e non così intuitivi come aggiungere oggetti entità a un altro elenco.

Answer 3

La mia più grande raccomandazione sull'utilizzo del modello di repository per l'incapsulamento dell'accesso ai dati (che in effetti è uno schema molto valido), è quella di poter creare un repository generico. Ma per creare un repository generico molto intelligente che fornisca fondamentalmente un cablaggio live per l'accesso immediato a tutte le operazioni CRUD standard, insieme all'accesso al complesso costrutto di query che non verrà esposto oltre la facciata di ISomeService.

La cosa più importante dell'utilizzo di un repository generico è che si desidera che sia basato sull'iniezione del costruttore e non sull'ereditarietà. In questo modo puoi comporre il tuo SomeService in modo che dipenda da molti repository generici di cui avrebbe bisogno per soddisfare un limite significativo del dominio aziendale.

Ho scritto un blog approfondito su questo concetto. Creating a common generic and extensible NHiberate Repository version 2. Sebbene questo post del blog sia specifico in riferimento a NHibernate, puoi prendere gli stessi concetti di base e applicarli a quasi tutti gli DAO.

Nota con alcuni strumenti, come Entity Framework, Linq2Sql e RavenDB per citarne alcuni, espongono i repository molto raffinati stessi e potrebbe non necessariamente beneficiare dell'aggiunta di un ulteriore wrapper.