6 Answers
6

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.

"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!" Well dont you need to do a lot of configuration files to each class? Or did i miss something
–
JohnAug 27 '09 at 18:04

You DO have a configuration file, but it's trivial. You have 1:1 configuration file for each class, which basically establishes the linkage between the Class and the Table (and the columns and the class's members). See step3 at: hibernate.org/362.html
–
DarkSquidAug 27 '09 at 18:18

2

The configuration file is trivial, until a change occurs somewhere along the chain that gorks the ENTIRE system. One small error and your system is down (like mine is now, hence my hunting on SO looking for the answer). Time saver in the beginning, sure, but once in a medium-complex system... LOOK OUT!
–
CampbelnJun 5 '12 at 23:52

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?

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.

Its just i can write it faster in SQL not have to figure out all kind of configuration shit and in the end my pure SQL is prolly alot faster. Btw i asked because i need to use it in a project and i needed some motivation
–
JohnAug 27 '09 at 17:56

Honestly NHibernate is pretty great when you get into it. I would check out the Fluent NHibernate project if the configuration is getting in the way.
–
Ryan MontgomeryAug 28 '09 at 18:32

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.