Question

I currently split out my Unit of Work and Repository objects into their own project, which accesses a different project which contains all the OR/M (nHibernate) code.

I’ve heard arguments that this is just an unneccessary abstraction and that I should be using my OR/M as the repository and unit of work.

What are the opinions and reasons for either doing this or not doing this?

Answer 1

There are at least three advantages to split OR/M and Unit of Work and Repository

• Inversion of control and more simple configuration — both Unit of Work and Repository abstractions
  should not directly depend on nHibernate. Thus you’ll get advantages of decoupled code, obvious way to follow SRP, and other SOLID principles. And possibility to get rid of nHibernate where it is not required.
• Execution speed and simplicity of unit tests — unit testing with possibility to mock/stub both Unit of Work and Repository without having nHibernate running in backgroud
• Design by contract — establish separate contracts for Unit of Work and Repository without mixing with nHibernate

ps: do not get me wrong, I count nHibernate one of best OR/M available for .Net, but often it’s just unnecessary to have it everywhere in code.