Is it a good idea to wrap my DbContext in a Unit of Work class?

Question

I am trying to implement Unit of Work/Repository pattern in my MVC Web application.

Since DbContext itself is a unit of work, I want to mix it with my own UOW for testing and decoupling purposes (decoupling business layer from EF). Is it then a good idea to just wrap my DbContext inside an UOW class like the following?

Example:

Code reduced for clarity

public interface IUnitOfWork
{
    void Save();
}

public MyContext : DbContext
{
    // DbSets here
}

public UnitOfWork : IUnitOfWork
{
    public MyContext myContext { get; set; }

    void Save()
    {
        myContext.SaveChanges();
    }
}

Then I would call UnitOfWork instance to perform data operations.

Thanks a lot in advance :-)

Jiggered

I advice you read SPORTSTORE section in this book amazon.com/Pro-ASP-NET-MVC-Adam-Freeman/dp/1430242361 There full explain one way for using Repository pattern – Uno

I am no architect and I had the same question in mind a couple of days back, and did take the same approach as you showed in your code. Initially I inherited the DBContext directly in my UOW! But later I was told to wrap the context in my UOW. Explanation was that the responsibilities of UOW and the context need to be clearly defined. After that I did not get time to study on this topic. So will follow this post. – Lateritious

DbContext class is implementing UnitOfWork pattern by itself. It's mostly an additional pain to work with wrapped DbContext. Create some Data layer abstraction and I think it's enough. And don't use Repository pattern :) it's also useless one imho – Theorist

@Theorist Mikhalevich I will think about that :-) – Jiggered

I agree with @AndreiMikhalevich. DbContext, itself, implements UoW/Repository pattern, there's no need to do it again. The only thing I would recommend is a service pattern, to abstract away the fact that you're using EF. In other words, all your controllers will only ever access your service layer, so you could switch EF out for NHibernate, or even a Web API, and it makes no difference. – Joyjoya

@Chris Pratt After thinking and examining some code I have decided to let go of adding another UOW/Repository over the existing one (DbContext). Thanks – Jiggered

The DbContext to NOT implement the Repository pattern. The pattern is an abstraction, DbContext is not a complete abstraction as you have to know how the EF LinqToSql provider works. – Crier

@Crier You are right. It is not a repository, but it is a Unit of Work as far as I know. – Jiggered

what about having 3rd party data providers polluting your domain services? better abstracted? – Pointblank

Answer 1

I depends on what you are trying to accomplish.

I you want to create an abstraction layer between Entity Framework and your business logic, then yes, it's a good idea. But then you have to do a complete abstraction meaning that your repository classes can not expose IQueryable<T>.

If you don't create a complete abstraction, then I do not see any reason to wrap the DbContext in a unit of work class.

Crier

When would you want to create that abstraction? – Jiggered

@Kamran: to be able to unit test your business code. – Crier

Marked as answer dude. – Jiggered

As of today, is creating an abstraction of data layer the only way to unit test business code? I hear things like in memory db etc - does that negate the need for the abstraction layer? – Lebanon

No, it does not. Linq to Memory doesn't work in the same way as Linq to sql. – Crier

Separating them also leads to a lot less complexity in both layers. That in turn leads to less bugs and easier to unit test the code. – Crier