Tradeoffs using NHibernate 3.0 QueryOver or LINQ provider

Question

I have not found a clear comparison of what is supported with the NHibernate 3.0 LINQ Provider compared to using the QueryOver syntax. From the surface, it seems like two large efforts into two very similar things.

What are the key trade offs to using each?

Answer 1

LINQ and QueryOver are completely different query methods, which are added to the ones that existed in NHibernate 2 (Criteria, HQL, SQL)

QueryOver is meant as a strongly-typed version of Criteria, and supports mostly the same constructs, which are NHibernate-specific.

LINQ is a "standard" query method, which means the client code can work on IQueryable without explicit references to NHibernate. It supports a different set of constructs; it would be hard to say if there are more or less than with QueryOver.

My suggestion is to learn all the supported query methods, as each use case is different and some work better with one, some work better with other.

Answer 2

I have used both NH-Linq-providers (the old NHContrib for Version 2.1, and also the new for NH3.0) and also used QueryOver. With all the experience made during development of quite complex data-driven applications, I would strongly suggest NOT to use the existing linq-provider with nHibernate if you plan to go behind just basic CRUD-operations!

The current implementation (linq) sometimes produces really unreadable and also unefficient SQL. Especially joining some tables quickly becomes a nightmare if you want to optimize database-performance.

Despite all these drawbacks, I did never encounter wrong queries. So if you don't care about performance and are already familiar with LINQ, then go for NH-Linq. Otherwise QueryOver is your realiable and typesafe friend.

Answer 3

LINQ to NHibernate (as of version 3.0) does not support the .HasValue property on Nullable types. One must compare to null in queries.