6

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 :-)

Kamran
  • 750
  • 11
  • 32
  • 1
    I advice you read SPORTSTORE section in this book http://www.amazon.com/Pro-ASP-NET-MVC-Adam-Freeman/dp/1430242361 There full explain one way for using Repository pattern – Elvin Mammadov Aug 12 '13 at 11:48
  • 1
    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. – Nilesh Aug 12 '13 at 11:56
  • 2
    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 – Andrei Aug 12 '13 at 12:15
  • @Andrei Mikhalevich I will think about that :-) – Kamran Aug 12 '13 at 12:25
  • 1
    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. – Chris Pratt Aug 12 '13 at 16:12
  • @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 – Kamran Aug 14 '13 at 10:36
  • 1
    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. – jgauffin Aug 16 '13 at 08:48
  • 1
    @jgauffin You are right. It is not a repository, but it is a **Unit of Work** as far as I know. – Kamran Aug 16 '13 at 18:00

1 Answers1

4

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.

jgauffin
  • 95,399
  • 41
  • 227
  • 352