C# – Is Unit of Work Pattern Needed with Repository Pattern?

asp.net-mvccentity-frameworkrepository-patternunit-of-work

I am trying to use EF6 with my project. I just watched Repository Pattern with C# and Entity Framework, Done Right | Mosh video. I understand the necessity of Repositories but I still don't understand UnitOfWork. I already have my DBContext to use instead of UnitOfWork. In the sample code of the video it is like:

using(var UnitOfWork = new UnitOfWork(new DBContext()))
{
    UnitOfWork.Courses.Get(1);
}

I don't understand the benefit of this. I can just directly use my dbContext in all of my repos,

using(var dbContext = new DBContext())
{
    var courseRepo = new CourseRepo(dbContext);
    var otherRepo = new OtherRepo(dbContext);

    courseRepo.Get(1);
}

So my repositories will be using the same dbContext. What is the reason of UnitOfWork then?

Best Answer

The Entity Framework DbContext is a unit of work, and its DbSet<T> properties are repositories.
That's not to say that you should never roll your own layer on top of them, but you're correct in asserting that the db context, in the way you're using it, precludes the main goal of a unit of work.

Your situation is quite unique in that you manually inject your context into your repositories, which gives you (the consumer of the repositories, i.e. whichever class contains the using block) direct control over the context and when it is committed.

That's not the case for a lot of other codebases, where the repositories conceal the EF dependencies and thus don't allow the context to be used outside of the repo. That leads to an inability to control the context on a layer above the repositories, which makes it hard to direct a transaction that spans multiple repositories.

In such a case, a custom built unit of work makes sense, as it give the consumer indirect control over the db context via the unit of work.

In short, in an Entity Framework context, a unit of work should only be used as an non-EF-dependent interface on top of your EF context.

To summarize, I want to address your actual question and the question I think you were actually asking about:

Is unit of work pattern really needed with repository pattern?

Yes, as it orchestrates atomic data operations that span more than one repository. Think of a unit of work as the director (uow) of an orchestra (repositories).

Is unit of work pattern really needed with Entity Framework?

Not necessarily. EF already provides the unit of work pattern for you. The only reason to still have a unit of work is if you:

  • want to include non-EF-datasources in an atomic data operation.
  • want to use a unit of work in your domain without relying on an EF dependency on that layer.
  • need a unit of work with a richer feature set than what EF provides - though this can in some cases still be done by extending the db context rather than wrapping it.

Not a direct answer to your question but tangentially relevant, I've written a lengthy answer on the benefits of units of work and repositories in conjunction with Entity Framework. It may be an interesting read for you as you're dealing with the same subject matter.

Related Topic