1

Is it bad if I use Nhibernate HQL instead of queryovers and joins?

I am trying to query a lot of data from a database and its hard to construct the queryovers due to the complexity of the requirement. One is I should project separately two or more fields belonging to a single column (i have no idea to do this, im just a noob in nhibernate)

I am thinking now to do it by HQL. Is it ok? :(

raberana
  • 11,739
  • 18
  • 69
  • 95

2 Answers2

1

I would like to append my answer, coming from my experience: Prefer Criteria or QueryOver API over HQL.

This is article is the starting point for argumentation: http://ayende.com/blog/4042/nhibernate-queries-should-i-use-hql-or-criteria. A small extract, cite:

... HQL is how NHibernate exposes most of its power... Its similarity to SQL means that it is often very intuitive when it comes the time to write and read it

Its biggest weakness, however, is when you want to perform queries using some dynamic criteria. For example, if you want to have a search page with multiple optional search fields. For that scenario, we have the Criteria API, which allow us to dynamically, painlessly and easily compose queries. ...

I would like to sign off the second paragraph! Sooner or later, you will move your Application (server part / data layer) to some point, where you will do some general stuff. Common paging, ordering, filtering...

Criteria resp QueryOver over HQL

To create valid HQL will require more and more effort, because you will be doing almost all the job yourself.

With the Criteria/QueryOver API, you are just calling standard methods Join, Where, OrderBy.... Do not worry how to put all the pieces together (e.g. WHERE x AND y ... the injection of " AND " operator).

So, do know HQL, but learn Criteria resp QueryOver API... and use THEM

EDIT: Projections in Criteria world are fun.

What's more important, they can be encapsulated into objects, custom projections or custom bundles of projections. Therefore we can gain reusable code, which can hide some complexity of the implementation. But because they are objects, we can Test them and later count on them

And we also can implement custom Transformer, which could bring even more benefits. See example here

Some examples of Projections:

https://stackoverflow.com/a/18885527/1679310

Community
  • 1
  • 1
Radim Köhler
  • 122,561
  • 47
  • 239
  • 335
  • nobody mentions projections... projections make me wanna use hql over queryover... of course you do not want to get all the columns so that is why you use projections, but what if the columns required are too complex to get (like my scenario above) is criteria/queryover still a good choice, i think they are only good at composing the filter of the query, and not in selecting the columns you want in your query result – raberana Dec 27 '13 at 02:32
  • I've updated my answer. The point here is, that I am trying to discourage you from HQL. I went this way. Thought it is/was cool. But after while I was lost in my own string parsing QL. `StringBuilder` became my friend, and any update to a query became a nightmare. The API of criteria is ready to do the same. It is not so straigthforward as HQL (looking so similar to SQL). But it will change after while. You gain the ability to work with objects encapsulating parts (projections, ordering, filtering, subselects). Summary: despite of the sexy look and feel of the HQL, please, at least try other.. – Radim Köhler Dec 27 '13 at 06:13
0

The disadvantage of HQL is that it is not typesafe. It is as if you where writing TSQL in C# code. It is just producing smelly code. And if something changes in your domain model, you have great potential of running into strange exceptions because of out of sync code...

But if this is not something you worry about, it's up to you I'd say ;)

MichaC
  • 13,104
  • 2
  • 44
  • 56