I have gone through many articles and I am still confused whether to use the Unit of Work pattern or not. I use generic repositories (Repository Pattern) but if my understanding of the UOW pattern is correct, most persistence tools today offer a unit of work pattern already implemented (DbContext, ObjectContext, DbSet).

I want to know if, in such cases, we should not try to implement the UOW pattern altogether? or I did see in one of the articles (sorry can't reference it since I missed it somewhere) that they had wrapped the DbContext inside an UOW class and I was left wondering what reason they might have of doing so.

4 Answers 4


DBContext only provides you with a UoW pattern if you code up all the changes in one go yourself, which is pretty much no different to writing a single query in SQL yourself.

You should use the UoW pattern if performance is your concern - writing a single hit to the DB is better than writing 1 hit per change. However, most people use an ORM for RAD tooling ease-of-use, not performance. If this is what your solution is focussed on, then forget UoW. If you need performance then you should be considering rolling your own UoW pattern by using direct SQL anyway.

  • 6
    I thought the purpose of UoW is to make something atomic, not for performance.
    – jhewlett
    Sep 27, 2013 at 23:02
  • 2
    @jhewlett: it is, in addition to what gbjbaanb said. martinfowler.com/eaaCatalog/unitOfWork.html Sep 28, 2013 at 1:11
  • So what you are saying that UoW would not really be any effective with any ORM?
    – Farax
    Sep 28, 2013 at 7:34
  • eh, so since DBContext IS a unit of work, then it will have said performance increase.
    – ozz
    Feb 6, 2014 at 11:20

I have went through this loop in the last few years, Unit Of Work, wrapping of repo's all calling Entity Framework.

You end up with a lot of pointless repository classes (with associated interface), probably wrapping a generic base repo class with a Unit Of Work on top that has lots of properties which expose the repo's.

And yes, you are correct, Entity Framework IS essentially a unit of work with repo's.

I am now at the point where I won't be doing that again for my next "from scratch" project and I'm looking at something more like this from Jimmy Bogard. (He's using an NHibernate session, but could equally be replaced by EF)

But what about mocking out the DBContext for unit tests? This can still be achieved by creating a Fake DBContext.

Please note. this is not a recommendation as such, just my current way of thinking, and I'm happy to hear about any issues this approach might have.

  • You end up with a lot of pointless repository classes this is so true. So many people eagerly implement UoW becasue they've heard somewhere it's good to use patterns but never ask themselfes, does implement it make any sense? What are the advantages? Mostly none in this case.
    – t3chb0t
    Oct 4, 2016 at 10:22

Not everyone of us has the luxury of using a framework which provides a built-in "Unit of Work" component.

If you are using Entity Framework's DbContext and it serves you well, use it. If it doesn't, you may have to implement your "Unit of Work" yourself.


I actually wrapped Entity Framework DbContext and DbSet into my own generic classes that follow the unit of work. The main reason to do so is unit testing.

I got my IUnitOfWork and IRepository interfaces that actually have got two implementations.

First one is EFUnitOfWork which wraps DbContext and IRepository for DbSet. This injected in production code whenever I expect an UnitOfWork.

Second one is a substitute for IUnitOfWork (I do use NSubstitute for doing mocks) and my own ListBasedInMemoryRepository that, as the name suggests, stores data in a list instead of Database.

This implementation is used in unit tests whenever I want to test code that would normally use Entity Framework. So my tests are now independent of actual database connection as they should be.

  • And what did you win by doing this? Testing for the sake of testing.
    – t3chb0t
    Oct 4, 2016 at 10:27
  • 1
    I'd say he gained the ability to test his domain rules without the DB running. A lot of very experienced people think that's a win. YMMV Dec 14, 2017 at 4:04
  • @IainDuncan but you can test the domain rules without using UOW, just mock the repositories Mar 5, 2022 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.