Question

I am making progress but still struggling with Unit of Work in a multi layer MVC app. Looking at the example here: http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application the UoW wraps all of the Repositories and provides each with a copy of the same dbcontext. Then the controller can use the Repositories with something like:

var courses = unitOfWork.CourseRepository.Get(includeProperties: "Department");

Now suppose You have a Service layer which accesses the Repositories instead. You could configure it so that it has a dependency on an IUnitOfWork implementation, then pass in an EfUnitOfWork implementation via Unity. Then when the Service completes some task it can call unitOfWork.context.SaveChanges(). But this approach hides the real dependencies for the Service; the repositories it needs. It also means that testing the Service requires you build a full UoW.

So I was thinking there must be a different approach and am wondering if one of the following or what I mentioned above (or something else!) is the correct approach:

• Service takes in the same repository arguments and also an IUnitOfWork. The repositories are wired up with a copy of dbContext courtesy of Unity. The EfUnitOfWork is also wired with the same copy. The Service can then use the Repositories as before and once finished use EfUnitOfWork to commit.
• Service just takes in an IUnitOfWork but sets up its required Repositories by passing to them a copy of the passed in IUnitOfWork.dbcontext

Please help!

James

Answer 1

Right so having explored the issue futher I have come to the following conclusion so thought I would document here to help others or so that i can be corrected should my findings be wrong.

DbContext is a Unit of Work. I only need to pass this Unit of Work into the implemented EFRepository classes. It does not need to go into the Service classes. So how does a Service class call context.SaveChanges() to ensure all related changes are coordinated when it does not have an instance of DbContext? Well it calls EFRepository.Save() which looks like the following:

public void Save()
    {
        context.SaveChanges();
    }

With this approach, Service classes depend only on Repositories. This will be clear and can be mocked for testing. When Unity injects the required Repository objects into a Service, it can provide each Repository with the same DbContext. In addition, only Repositories have access to the DbContext.

All of this may be obvious but it had me stumped. Or it may be plain wrong, in which case please let me know!

James