nHibernate, Linq and Queries

I have been using nHibernate a lot in my latest project. nHibernate is a persistence layer, it handles mapping of entities (objects) to a database or other storage medium. In this case a SQLServer database. I am not going to go into a big introduction to nHibernate here as there are many excellent resources for that available (http://blogs.hibernatingrhinos.com/ for examples).

Learning nHibernate initially wasn’t very hard, in fact it really couldn’t be much simpler. Mastering nHibernate, and specifically the art of persistence and domain-driven design has been more difficult. I have relied on several online blogs, one of them being Ayende Rahien’s blog.One specific problem has been exactly how best to separate the program into layers, often called separation of concerns. This involves separating out things like the Presentation/UI layer, the domain/model or sometimes “business” layer and the data access layer which typically handles persistence. A common sample of building an application this way using nHibernate is this sample of “best practices” which is often used by people new to nHibernate as a starting. This was also what I used to learn with as well.

Despite being very easy to understand an implement I I find this design lacking in ways I find hard to describe, needless to say I find it clunky in some respects which is why I was really interested by this post by Ayende. Ayende has argued a few times (and I am sure I will explain this poorly) that nHibernate really is the data layer and that building an entire data layer on top of nHibernate is overkill.

Anyways, I didn’t want to refactor my entire program just yet to eliminate my DAL so instead, to try out this IQueryable approach I added a simple method to the AbstractNHibernateDao<T> class:

public virtual IQueryable<T> GetQuery()
{
  return (from entity in NHibernateSession.Linq<T>()
    select entity);
}

This is basically a method using generics which returns a generic query from Linq2Nhibernate. It is very similar to Ayende’s example, but it doesn’t have any query logic. That is ok though since whatever asks for the query can easily extend the query using .Where().

I am curious what people think about this approach. Is it sensible, or can you foresee pitfalls to it?