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.