NHibernate and Repository pattern

Question

What is the recommended approach to take with Nhibernate + Repository pattern?

There are so many different articles and opinions around that I am not sure what path to take. Take this lengthy article, for example. It gives an example of Query objects, but each concrete repository accepts an ISession in its constructor. What should I care about NH sessions in my BL (business layer)?

1. Create a bunch of repositories, each of them having a bunch of specific methods?
   Apparently, that's too much work because BL is now "allowed" to be aware of NHibernate (Repository is the new Singleton)?

2. Create a single generic repository, but expose IQueriable<T> and use LINQ in BL
   Every now and then there is a query which LINQ-to-NHibernate won't be able to process (or I need to tweak the SQL manually once in a hundred queries). This is easy with custom repo methods, but next to impossible with code relying on LINQ. And using both just because LINQ is broken in some cases is nonsense.

3. Query objects?
   QueryOver is also NH-specific, which means BL is again aware of the DAL implementation.

4. Yet Another Approach?

Obviously, I need to be able to manage transactions somewhere, maybe using a Unit-of-work patten (although there are also many different implementations of that around).

Answer 1

There are many conflicting opinions within the world of software architecture and many of these are very well-founded.

1) Yes, defining a repository for each aggregate root can be overkill, but you might find that the way you retrieve data for that root may be specific to it and you want to be able to control it in a custom repository. Ayende's article is very telling and hits closely at the typical developer's desire to 'over-architect' solutions - often to the detriment of functionality.

2) Using LINQ with NHibernate is an option but I would stress that you must give yourself the ability to fall back to using criteria queries or HQL if you do this. At that stage you might find yourself putting in so many exceptions you'll wonder what the initial point of the abstraction was.

3) QueryOver is a type-safe wrapper around criteria queries and this alone makes them far more attractive to me. I so often find myself falling back to criteria for the sheer control that they offer - the fallback often being that I have to use "magic strings". This would essentially make NHibernate your data access abstraction. In fact, it would be a better abstraction that most 'repositories' because most of them just provide CRUD methods...a repository should be able to handle query specifications (exactly how QueryOver works).

As far as transactions go - it depends on your framework. In reality I don't think its realistic or beneficial to use the unit of work pattern in an application and hide the implementation from it (you could abstract it - but what's the point? - are you really going to change your ORM?)

If you're using ASP.NET then just (at minimum) start the transaction at the start of the request, rollback on exceptions and commit at the end.

If you're using WinForms then you may need to consider the lifespan of each UI task to be your unit of work.

Answer 2

The site seems to be down now but I really like Bob Craven's approach and have used it on some big projects:

http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/ EDIT: Google cache version of the link

He uses generics and a UOW pattern for data access.

Yes it's a slight pain when you need to fall back on SQL but I use a Data Service layer which can abstract that. I.e. Data service layer uses the generic dao's where possible (90% of the time) and uses vanilla SQL/other frameworks in other places.