You mentioned “I was imagining using one, database-wide, unit of work class”.

I have just begun to design a Unit of Work pattern and had the same concern.

I had been considering one approach which might solve the concern quoted above, but I’m not yet sure of it and I’ve yet to try it. Basically, it utilises the CQRS pattern. Here it is..

Similar to CQRS pattern, where each use-case has a unique pair of Command class and Command’s handler class, how about if we create different UnitOfWork classes for each use-case. This, each use case will now have 3 things, command, its handler and a UoW class.

In CQRS, usually, the handler contains (is dependent) only on the repositories required by it. In my proposal, the repositories needed by that handler may be moved to its UoW class. In the handler, UoW will be injected instead of the repositories.

In this way,

• we avoid instantiation of unnecessary repositories,

• overhead is removed

It has all Pros of CQRS. UoW is more granular, which is the selling point of CQRS, more maintainable for changing logic with evolving business logic etc.

Anyone buying?