Differenze tra creare il proprio UoW/Repository vs utilizzare DbContext direttamente

Question

La descrizione per DbContext dice: "Un'istanza di DbContext rappresenta una combinazione dei modelli Unità di lavoro e Repository ...". Ma molti sviluppatori tendono a creare i propri repository e UoW.

Devo utilizzare direttamente DbContext e DbSet o dovrebbero esserci i miei propri repository? Quali sono le differenze?

C'è qualche problema se utilizziamo lo DbContext direttamente? Che ne dici se passerò da MS SQL a Oracle in futuro?

Answer 1

Seguire MSDN

Altre volte, si consiglia di scrivere il proprio specifico dell'applicazione Unità dell'interfaccia lavoro o di classe che avvolge l'unità interna del Lavoro dal vostro strumento persistenza. Puoi farlo per una serie di motivi. È possibile che desideri aggiungere la registrazione, la traccia o la gestione degli errori specifici alla gestione delle transazioni. Forse si desidera incapsulare le specifiche degli strumenti di persistenza dal resto dell'applicazione . Potresti volere questo incapsulamento extra per semplificare lo scambio delle tecnologie di persistenza in seguito, . Oppure potresti voler promuovere la testabilità nel tuo sistema. Molte delle implementazioni integrate di Work of Work da strumenti di persistenza comuni sono difficili da gestire con scenari di test automatici dell'unità.

Torna alle tue domande.

Devo utilizzare DbContext e DbSet direttamente o dovrebbero esserci i miei propri repository ?

In effetti, non c'è alcun problema quando si inseriscono DbContext e DbSet nei repository. Ci chiederemo da soli vorremmo testare più facilmente o meno. Se vogliamo progettare un framework che collauda tutto, non dobbiamo usare DbContext e DbSet direttamente nel vostro Repositories. Dovremmo usare l'interfaccia IDbContextFactory che è usata per fornire DbContext, solo i miei due centesimi.

Per avere più viste sull'archivio, è possibile prendere riferimento al seguente collegamento per considerare le opzioni tra repository e DbContext.

http://huyrua.wordpress.com/2010/07/13/entity-framework-4-poco-repository-and-specification-pattern/

C'è qualche problema se si usa il DbContext direttamente?

No, non c'è alcun problema se si utilizza DbContext direttamente. Ma incasinerà molte regole di business e un sacco di problemi di scala come database centralizzato, difficile da testare e violare separatamente le preoccupazioni nel principio di progettazione.

E se passassi da MS SQL a Oracle in futuro?

In realtà, non c'è alcun problema quando si passa da MS SQL a Oracle in futuro. Devi solo cambiare fornitore di dati seguendo il link sottostante quando usi DbContext di Entity Framework.

http://www.devart.com/news/2008/directs475.html

o MS Entity Framework Oracle Provider