Is unit of work pattern really needed with repository pattern

Question

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?

Answer 1

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.

Answer 2

The Unit-Of-Work pattern makes sense when you have a complex use case with several objects involved, often objects which map to different master-detail tables. As part of the use case, you want to

1. pull all the required objects out of the database

2. let the user edit these objects (his local copy), until they are satisfied with the result. "Edit" here may mean to add or remove new "detail objects", or undo and redo certain steps.

3. Finally, write the result set of objects back to the database in one transaction (or give the user the opportunity not to write the changes back, in which case nothing is changed in the DB).

For example, such a use case could be the creation of an order for an online shop (with several items involved, an ordering adress, a billing adress, a method of payment etc). Or it could be the editing of a complex structural component for a software supporting the construction of buildings. Or it could be the editing of an insurance contract, where the contract is not just a single-record document, but split-up into several objects with a lot of meta data.

For all these case, it makes sense to have a coordinating object which keeps the related data together and tracks the changes to the involved objects, so they can be written back to the database "at a whole", in a transactional and optimized fashion. That is what the Unit-Of-Work object is for. Steps 1 and 3 will usually make use of repositories.

Of course, when an ORM like EF supports automatic change tracking, for use cases which can fully rely on that in-built mechanism, an UoW may not be necessary. But "interesting", real-world requirements are not always that simple: EF's automatism may not be sufficient or not performant enough, or there are other systems or technologies or layers to be included.

So the UoW is just an extra layer between the repositories and a certain service or use case implementation, designed for the specific use case's needs. It is definitely not necessary for use cases like trivial CRUD operations on a single DB table, or use cases which are only slightly more complex, like the simplistic examples shown in the question.

Answer 3

I think there is one other aspect to consider, regardless of what has been brought up earlier, and that is the matter of decoupling technology (Entity Framework / EF Core via the DbContext) from business code.

This is generally desierable, but how this is obtained for each specific real world scenario are discussions better suited some place else. However, one way to achieve this breaking of dependancies would be to contain the DbContext (being a Unit of Work in itself) inside another class. How to do this is of course a matter of taste, but I feel as if this perspective should be represented alongside the other ones previously provided.