44

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?

dotjosh
  • 615
  • 7
  • 11

4 Answers4

37

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.

Diego Mijelshon
  • 52,548
  • 16
  • 116
  • 154
  • 1
    Fetching and Caching seem to be supported with the LINQ Provider, I'm just wondering if there would be any similar technical walls (join scenarios, etc) that I could run into. – dotjosh Oct 06 '10 at 19:52
  • 8
    LINQ doesn't yet support left joins, for example. – Diego Mijelshon Oct 06 '10 at 20:07
  • 1
    Exactly the kind of thing I was wondering, if anyone could contribute to this list I'm sure it would be helpful to myself and others. – dotjosh Oct 06 '10 at 20:33
  • 2
    In my opinion Linq syntax for join is very ugly and leads to unreadable code. I this reason I use Criteria API and QueryOver. – Darius Kucinskas Mar 01 '11 at 11:10
  • 3
    Isn't linq for NH actually based on criteria / QueryOver? It is impossible that Linq has more features. It only can have less. – Stefan Steinegger Mar 02 '11 at 10:14
  • 1
    @StefanSteinegger: no, it's not. The old contrib provider for NH 2.x was; the new one is based on the HQL engine. – Diego Mijelshon Mar 02 '11 at 10:48
  • @Diego: wow, I didn't know that. This is a major change and would allow it to be much more powerful. – Stefan Steinegger Mar 02 '11 at 11:02
  • 4
    @Stefan: No, actually not. Altough the new provider is by far better than the old one (which was really poor), it is still far away from being complete. In fact, there has been some discussion before the NH3-release, wheter LINQ-support should be called "Beta" - with good reasons for doing so. However, it seems that Fabio Maulo decided not to call it what it is - an incomplete beta. – Daniel Lang Mar 08 '11 at 18:33
  • The LINQ provider currently has bucket loads of bugs, for example SUM() doesn't work. The QueryOver, while the refactor/magic-string removal is nice, is quite a bit slower than just writing SQL in my view. That's mostly down to the lack of documentation beyond 1 page on nhforge – Chris S Aug 20 '11 at 17:43
17

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.

Daniel Lang
  • 6,819
  • 4
  • 28
  • 54
  • 2
    An example out of the real word: One task with `Query` took 10s. Changed to `QueryOver` without any other changes: 1s – bentolor Aug 21 '15 at 11:29
  • @BenjaminSchmid would be good if you could show that query, even with names changed etc just to see the rough complexity of what could take longer – PandaWood Dec 07 '16 at 23:28
15

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

Marcel
  • 15,039
  • 20
  • 92
  • 150
2

I started to use NH-Linq, because i was already done with LinqToSql and Entity Framework. But, for more complex queries, i have always finished with QueryOver. Reasons:

  • It's happen that query with NH-Linq doesn't work as expected. I can't remember exactly, but it doesn't work correct with some complex queries. Seems that is too young. And as dlang stated in previous answer, it's produce unefficient SQL.
  • When you learn QueryOver, it's easy to call functions, do projections, subqueries, seems to me more easy then with NH-Linq.
  • Good thing for NH-Linq - it can be extended, like Fabio Maulo explained here. But, similar is quite possible with QueryOver, but not so fancy as with NH-Linq :)
vllado2
  • 170
  • 1
  • 7