Question

I am currently building an ASP.net MVC application, which has be broken down into multiple modules (as well as a generic class library).

I have implemented a Unit Of Work pattern for my first module. This unit of work class contains a number of different repositories.

However, I was wondering whether or not it is good idea to have a separate Unit Of Work class for each module?

Answer 1

Well, EF supplies you with UnitOfWork and Repository patterns implemented itself. Usually they are not exactly what you want and it seem nice to add some methods to that native EF Repositories, but in most cases it doesn`t worth the trouble.

Implementing your own Repository based on EF is not a good idea if your project is simple. It adds a lot of work but not as much of value.

Implementing UnitOfWork based on EF is complete different story. The only reason i can see to do it is “to have different UoW for different parts of the solution”. Avoid it otherwise, really.

We tried to add both this approaches ignoring prebuilt ones in our project. It was completely reasonable because we were designing modular solution and we didn`t even know how many modules we would have at the end. We expected to add new modules to the system when it is already running and heavy loaded. And i can say that it took a lot of time to develop such application. When you realize that you need to have access to one more entity from some module leads to changes in several places – the first evidence of inefficient design.

So, KISS and YAGNI are against it. If you are tangled by question “should i add this stuff to my project” – just don`t. You need a good reason to implement this parts yourself, not just some “nice design” bias, because it adds lots of complexity. Even if you think you would need it some day – wait until that day. If you would try to estimate which miscalculation would be more disastrous i am pretty sure that it is much easier to add something new to your project then remove something already existing.