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)?

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)?
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.
Query objects?
QueryOver is also NH-specific, which means BL is again aware of the DAL implementation.
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).

@mathieu: yes. (I am not sure what other repositories I might think of.) But more generally, I am looking for a recommended way to organize an app written in 2011, with all the modern tools and patterns around. I have used NHibernate in several ways before, but I hate when I need to reference NH specific classes in my BL. And it seems like it's becoming common to say that NH doesn't need abstracting. — doe, Jul 22 '11 at 12:28
@doe - surely your NH-specific classes are simply your domain entities? else you're looking at considerable amounts of property-duplication and mapping. — David Neale, Jul 22 '11 at 12:35
And yes - it's becoming common to say that NH doesn't need abstracting because I don't know of any decent project where it's been successfully done. There are always dependencies that leak through. Frankly - I don't think the benefits add up. The BL (I tend to use a tasks or application layer concept) can have knowledge of NH. It should still normally be hidden from the presentation layer as much as possible. — David Neale, Jul 22 '11 at 12:40
@david: By NH specific classes I am referring to stuff like `ICriteria`, and classes related strictly to data access. Not entities. It wouldn't make much sense for me to whine about referencing *entities* in the BL? :) — doe, Jul 22 '11 at 13:03
Ah sorry I misunderstood - yeah I understand why you wouldn't want them there. However, it's worth questioning *why* you don't want it. — David Neale, Jul 22 '11 at 13:41

score 13 · Accepted Answer · answered Jul 22 '11 at 12:33

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.

At the time of comment you 1337 medals :) 6,907 s13 b37 I'm afraid to +1 because it might spoil the effect — Shagglez, Oct 17 '12 at 15:43

score 2 · Answer 2 · edited Jul 22 '11 at 13:18

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.

NHibernate and Repository pattern

2 Answers2