OlgaB
OlgaB

Reputation: 31

Nhibernate 3.2 Query vs QueryOver

Recently, we have updated our nHibernate to 3.2. Now, two new options added for us to write queries - Query (LINQ) or QueryOver(iCriteria).

From what I read, QueryOver is dedicated to nHibernate and more powerfull for complicated queries. On the other hand, LINQ is universal and if tomorrow I change my ORM, my queries stays as they are. Another important reason for me to use LINQ, is the fact that on LINQ I found much more documentation and examples than on QueryOver.

Actually, I prefer to use LINQ, and I want to be sure that there is no critical reason why i shouldn't do this.

Thanks in advance,

Upvotes: 2

Views: 4065

Answers (2)

Phill
Phill

Reputation: 18804

The chances of you swapping out your ORM are very slim to none.

Both QueryOver and Query have their pros and cons.

But the benefit of NH is that you can easily flick between any of it's querying capabilities. Where I work we use a mixture of QueryOver (primarily), Query, HQL and on occasion direct SQL.

While a lot of LINQ queries from NH will easily translate to EF, LightSpeed, or your choice of ORM, there is a whole heap of NH specific LINQ such as Fetching that are built into the LINQ provider that will make it difficult to swap-out the ORM at any point.

Sometimes QueryOver queries will generate better SQL than Query, and vice versa, so just use what you prefer and profile your queries when they are executed to ensure that the generated SQL is efficient.

Upvotes: 9

Wiktor Zychla
Wiktor Zychla

Reputation: 48279

As for now, unfortunately both have their limitations and there's a lot of work to be done by nHibernate team to match the expressiveness of Linq2SQL where most of queries just work.

Most of the time I use Linq (Query) but it has some unexpected problems on relatively simple queries which involve grouping and some subtle bugs (like the infamous "invalid cast" on byte? https://nhibernate.jira.com/browse/NH-2812). Switching to criteria api (QueryOver) usually helps.

As for now (3.2) it is then impossible to give a straight recommendation. I would stick with Linq, temporarily switch to criteria whenever you encounter issues and when bugs and limitations are removed in future versions, you could go back and try to rewrite everything to Linq as it should serve as the primary query language.

Upvotes: 3

Related Questions