Repository generico Con EF 4.1 qual è il punto

Mentre approfondisco DbContext, DbSet e le interfacce associate, mi chiedo perché avresti bisogno di implementare un repository "generico" separato attorno a queste implementazioni?

Sembra che DbContext e IDbSet facciano tutto il necessario e includano "Unit Of Work" all'interno di DbContext.

Mi sto perdendo qualcosa qui o sembra che la gente si diverta ad aggiungere un altro livello di dipendenza senza motivo.

In realtà hai ragione. DbContextè un'implementazione dell'unità del modello di lavoro ed IDbSetè un'implementazione del modello di repository.

I repository sono attualmente molto popolari e abusati. Tutti li usano solo perché ci sono dozzine di articoli sulla creazione di repository per il framework di entità, ma nessuno in realtà descrive le sfide legate a questa decisione.

I motivi principali per l'utilizzo del repository sono in genere:

• Nascondi EF dallo strato superiore
• Rendi il codice più facilmente testabile

Il primo motivo è una sorta di purezza architettonica e un'ottima idea che se rendi indipendenti i tuoi strati superiori su EF, puoi in seguito passare ad un altro schema di persistenza. Quante volte hai visto cose del genere nel mondo reale? Questo motivo rende molto più difficile lavorare con EF perché il tuo repository deve esporre molte funzionalità aggiuntive che avvolgono ciò che EF consente di default.

Allo stesso tempo, il wrapping del codice EF consente di organizzare meglio il codice e seguire la regola Separazione delle preoccupazioni. Per me questo può essere l'unico vero vantaggio del repository e dell'unità di lavoro, ma devi capire che seguire questa regola con EF renderà forse il tuo codice più facilmente gestibile e leggibile, ma nello sforzo iniziale di creare la tua applicazione sarà molto più elevato e per applicazioni più piccole questa può essere una complessità non necessaria.

Il secondo motivo è parzialmente corretto. Il grande svantaggio di EF è l'architettura rigida che può essere difficilmente presa in giro, quindi se si desidera testare l'unità di livello superiore, è necessario avvolgere EF in qualche modo per consentire di deridere la sua implementazione. Ma questo ha molte altre conseguenze che ho descritto qui .

Seguo il blog di Ayende . Se hai mai usato NHibernate probabilmente conosci i suoi articoli. Questo ragazzo ha recentemente scritto diversi articoli contro l'utilizzo del repository con NHibernate ma NHibernate è molto meglio deridibile.

Sto lottando con gli stessi problemi e la derisione per i test unitari degli strati EF è importante. Ma mi sono imbattuto in questo fantastico articolo che spiega come impostare il DbContext di EF 4.1 in modo da renderlo beffardo assicurandomi che il tuo DbContext derivato implementasse un'interfaccia generica ed esponesse IDbSet anziché DbSet. Dal momento che sto usando un approccio Database First, poiché il nostro database esiste già, ho semplicemente modificato i modelli T4 utilizzati per generare il mio DbContext derivato per generarlo per restituire interfacce IDbSet, nonché derivare dalla mia interfaccia generica. In questo modo l'intera cosa può essere facilmente derisa e non è necessario implementare la propria unità di lavoro o modello di repository. Scrivi il tuo codice di servizio per utilizzare l'interfaccia generica e quando vai all'unità testalo,

http://refactorthis.wordpress.com/2011/05/31/mock-faking-dbcontext-in-entity-framework-4-1-with-a-generic-repository/

Un motivo per la creazione del repository è che puoi nascondere l'implementazione di DBSet e DbContext se decidi di passare da EntityFramework a qualcos'altro o viceversa.

Ad esempio, stavo usando NHibernate e ho racchiuso tutte le chiamate a quel framework all'interno delle mie classi di repository. Restituiscono IEnumerable perché diventano "generici" e i miei repository hanno le operazioni CRUD standard (aggiornamento, eliminazione, ecc.). Da tempo mi sono trasferito in Entity Framework. Nel fare ciò, non avevo bisogno di cambiare nulla nelle mie classi ViewModel o oltre perché indicavano il mio repository - avevo solo bisogno di cambiare l'interno del mio repository. Ciò ha reso la vita molto più semplice durante la migrazione.

(Ho usato NHibernate perché ci stiamo collegando a ISeries e, al momento, non c'erano implementazioni a basso costo usando EF con ISeries. L'unico disponibile era pagare $ 12.000 a IBM per il loro DB2Connect)