Trade-offs using NHibernate 3.0 QueryOver or LINQ provider

I did not find a clear comparison of what is supported with the NHibernate 3.0 LINQ Provider compared to using the QueryOver syntax. From the surface, this seems like two great efforts in two very similar things.

What are the main tradeoffs for using each?

+43
linq nhibernate
Oct 06 2018-10-06
source share
4 answers

LINQ and QueryOver are completely different query methods that add to those that existed in NHibernate 2 (Criteria, HQL, SQL)

QueryOver is meant to be a strongly typed version of Criteria and supports basically the same constructs that are NHibernate specific.

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

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

+35
Oct 06 '10 at 16:18
source share

I used both NH-Linq providers (old NHContrib for version 2.1, and also new for NH3.0), and also used QueryOver. With all the experience gained during the development of rather complex data-driven applications, I highly recommend NOT using an existing linq-provider with nHibernate if you plan to abandon basic CRUD operations!

The current implementation (linq) sometimes creates truly unreadable as well as inefficient SQL. Especially when you join some tables, it quickly becomes a nightmare if you want to optimize database performance.

Despite all these shortcomings, I never came across the wrong requests. Therefore, if you do not care about performance and are already familiar with LINQ, go to NH-Linq. Otherwise, QueryOver is your real and typical friend.

+16
Mar 08 '11 at 18:28
source share

LINQ to NHibernate (since version 3.0) does not support the .HasValue property in Nullable types. It is necessary to compare with zero value in requests.

+15
Dec 29 2018-10-29
source share

I started using NH-Linq because I already worked with LinqToSql and Entity Framework. But for more complex queries, I always ended up working with QueryOver. Causes:

  • It happens that a query with NH-Linq does not work as expected. I don’t remember exactly, but this does not work with some complex queries. It seems to be too young. And as dlang said in the previous answer, it creates inefficient SQL.
  • When you learn QueryOver, it's easy to call functions, make projections, subqueries, it seems easier to me than with NH-Linq.
  • Good for NH-Linq - it can be expanded, as Fabio Molo told here . But it seems that this is quite possible with QueryOver, but not as fantastic as with NH-Linq :)
+2
Oct 12 '11 at 15:52
source share



All Articles