What reasons exist for using NHibernate?

Question

For those people that use NHibernate and similar stuff, why do you use it? To me, it seems easier to write the SQL manually.

Answer 1

Productivity and cross-database portability are two reasons. Hibernate/NHibernate or other ORMs allow one to easily serialize objects to/from the database without having to hand-code (and maintain) lots of SQL statements to do exactly that. I don't know about you, but writing and keeping tons of CRUD queries up-to-date for the hundreds of objects in our system is not my idea of fun, nor a good use of a developer's time! I'm not sure if NHibernate has a similar mechanism, but the Hibernate Synchronizer plugin for Eclipse is truly fantastic: take a mapping file and make objects and DAOs automagically. Good stuff!

Performance (in the L1 and L2 caches) is another reason -- though of course you can certainly write boneheaded findAll() type code which makes this moot, but overall they've put a LOT of time and effort into this, so it's more code you don't have to reinvent yourself.

Now sure, there's a nontrivial learning curve for N/Hibernate but like most things once you get it you'll wonder how you lived without it.

That said, ORMs aren't a silver bullet (though they are very good, generally) and they're not appropriate for all circumstances. We still write SQL for complicated or highly optimized queries. That said, the developers on my team swear by Hibernate and would probably revolt if we went back to writing straight SQL everywhere.

Answer 2

This question will probably help you out, there's a lot more ORM related questions on SO already, which largely cover NHibernate as it's the 'people's choice' along with Subsonic and Linq-To-Sql.

In short:

• It's very mature
• It supports almost all RDBMSs
• It has a big community and a lot of developers on the project
• It has powerful querying. Once you use HQL for collections you won't want to go back to joins
• It has a very fine level of object definition, particulary for collections

For projects without one-to-manys and many-to-manys, or complex querying it offers almost no benefits if you're new to it. There's a tonne of others that do this with a lot less steep learning curve.

Answer 3

What do you mean by easier? Assume the following a standard Order->Line Item->Product setup. If I want to find all orders with a line item for a product I can write this in HQL: select order from Order order, LineItem lineItem, Product product where product.id=:id and product.id = lineItem.product.id and lineItem member of order.lineItems

The SQL for that is much much messier. Especially if you have multiple pivot tables in the mix etc. Heck the SQL code for the "member of" phrase alone is worth avoiding. So is SQL easier to setup, yeah mostly. Is SQL easier to write? Not for any significant object model. So, what do you mean by easier?

Answer 4

While your question might be construed as fodder to start a religious battle I will assume you're honestly curious and would like to understand why NHibernate might make sense in some cases...

"Easier" is a subjective word. Do you mean to say it takes less time to create an app with plan in-line SQL? That might be true for your application. Sure. In my experience code is still dirty long after it was quick.

Do you mean plain in-line SQL is easier to read? I would argue that as the complexity of your application increases, you might find it far more difficult to read lines and lines of SQL, v.s. analyzing a well structured domain model.

The truth is, it just depends. No developer should marry themselves to a tool. NHibernate is a tool. I would submit that NHibernate is a really good tool for those in need of an ORM. But it becomes less useful when you only really need in-line sql.

If you're creating a t-shirt...you probably don't need a hammer.

Answer 5

One reason to use NHibernate that hasn't been mentioned so far is that using NHibernate allows you to use Linq. Most people agree that Linq is great.

You can't use Linq without a data layer that supports Linq and that generally requires an ORM. If you are going to use an ORM so you can use Linq, NHibernate is the best choice.

Writing SQL by hand is fine, but it is generally a lot more tedious than using an ORM. It just doesn't make sense to hand write SQL for CRUD operations when you are likely going to duplicate some of that "design" in your database, data layer, and business layer.

Once you decide that you don't want to write yet another set of CRUD SQL, you start to consider ORMs. Once you start to consider ORMs, you likely end up with NHibernate as the best choice.

Based on some of your comments, you definitely also want to consider Fluent NHibernate so you don't have to deal with manually writing the XML configuration files.