Differences between create our own UoW/Repository vs using DbContext directly

Question

The description for DbContext says :"A DbContext instance represents a combination of the Unit Of Work and Repository patterns...". But many developers tend to create their own repositories and UoW.

Should I use DbContext and DbSet directly or should be there my own Repositories ? What are the differences.

Is there any problem if we use the DbContext directly ? How about if I switch from MS SQL to Oracle in the future ?

Answer 1

Follow MSDN

Other times, you may want to write your own application-specific Unit of Work interface or class that wraps the inner Unit of Work from your persistence tool. You may do this for a number of reasons. You might want to add application-specific logging, tracing, or error handling to transaction management. Perhaps you want to encapsulate the specifics of your persistence tooling from the rest of the application. You might want this extra encapsulation to make it easier to swap out persistence technologies later. Or you might want to promote testability in your system. Many of the built-in Unit of Work implementations from common persistence tools are difficult to deal with in automated unit testing scenarios.

Come back to your questions.

Should I use DbContext and DbSet directly or should be there my own Repositories ?

In fact, there is no problem when you put DbContext and DbSet into your repositories. We will ask by ourselves we would like to test more easier ot not. If we want design a framework testing everything we should not use DbContext and DbSet directly as well into your Repositories. We should use interface IDbContextFactory which is use to provide DbContext, just my two cents.

To help you have many views about repository you can take reference the link below to consider options between repository and DbContext.

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

Is there any problem if we use the DbContext directly ?

No, there is no problem if you use DbContext directly. But it will messy many business rules and a tons of scale up issues as centralize database, difficult to test and violate separate of concern in design principle.

How about if I switch from MS SQL to Oracle in the future ?

Actually, there is no problem when you switch between MS SQL and Oracle in the future. You just only change data provider follow the link below when use DbContext of Entity Framework.

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

or MS Entity Framework Oracle Provider