Using an abstraction layer over DbContext

Question

DbContext in EF Code first implements Unit of Work and Repository patterns as MSDN site said:

A DbContext instance represents a combination of the Unit Of Work and Repository patterns such that it can be used to query from a database and group together changes that will then be written back to the store as a unit. DbContext is conceptually similar to ObjectContext.

Does it means that using another UoW and Repository abstractions(such as IRepository and IUnitOfWor), over DbContext is wrong?

In the other word does using another abstraction layer over DbContext add any additional value to our code?

Values such as technology independent DAL(Our Domain will depends on IRepository and IUnitofWork instead of DbContext)

Answer 1

Consider this - you currently have two strong ORMs, each having it's pros and cons over the other:

• Entity Framework
• NHibernate

Additionally there are several more micro ORMs, such as:

• Dapper
• Massive
• PetaPoco
• ...

And to make things even more complicated, there are clients / drivers for non-SQL databases such as:

• C# driver for MongoDb
• StackExchange Driver for Redis
• ...

And of course, one more thing that always has to be taken in consideration is whether there will be testing that would include mocking the data access layer.

Decision whether you should use UoW/Repository pattern should come from your project itself.

If your project is short-termed, with limited budget, and you are not likely to be using anything else but Entity Framework and SQL, then introducing UoW/Repository layer of abstraction will just take you additional pointless development time which you could have used in something else or completed project earlier and earned some extra cash.

However, if project is long-running and involves more complex development lifecycle that includes continuous testing, then UoW/Repository pattern is a must. With amount of databases that are now in usage and NoSQL movement coming heavily in .NET ecosystem, making a decision to nail selection of ORM and database might cause severe refactoring once you decide to scale out (i.e. scaling out with MongoDb is much cheaper than with SQL, so your client might ask you out of sudden to move everything to MongoDb). As sides are shifting constantly right now and new ideas are being implemented (such as combined graph+document databases), no one can make a good statement which database will be best choice for your project in 1 year from now.

There is no bool answer to this question.

This is just my point of view, and it is coming from developer who works on both short-termed and long-running projects.