I've used nHibernate for a few projects now, but I certainly don't consider myself an expert user. I'm skeptical that nHibernate is a better solution that using stored procedures [holding up my shield to deflect flaming arrows].

I'm sure there's a reason why so many people use nHibernate, so I guess I'm looking for you tell me about the positives about nHibernate that I'm not aware of. Here are some of my beefs:

1. When I ask most people what benefits you get out of nHibernate, they usually tell me that the mapping files save you the work of having to maintain CRUD procs and the loading/saving/deleting of your object using those procs. But I can use code generation and generate those procs just as fast as I can create a mapping file. So to me, the time-saving benefit of nHibernate is gone in this case.

2. We've spent a ton of time on our project trying to figure out how to do something in the mapping file. I'm sure that once I become an expert at mapping files it'll go a lot faster. But to me, it seems that I'm just learning another way to do what I already knew how to do in SQL.

3. Because people aren't experts at creating mapping files, they tend to make mistakes in their mapping files without knowing it. Usually this involves loading or saving of more than what you want to load or save. So your object will load and save correctly, but it might do a lot of other extra work that you don't know about. So you have to look at all of the output to see what exactly is going on to make sure that everything is working the way you want it to.

4. Sometimes I want to do stuff immediately after an object is loaded or saved. But because there are so many different ways to save or load an object (e.g. the object by itself, a parent object that contains the object, or a list the contains the object), it's difficult to know when those events happen. If I'm using stored procs, I know when everything is happening because I'm calling a constructor or I'm calling object.Save(). Yes, I might have to write a little more code to populate the objects from the database, but this is code that I can generate using a code generator.

Again, nHibernate obviously has value because so many of you use it, and I don't want to be one of these people who writes something off just because I don't understand it or it's not familiar with it. So please tell me if and why you think I'm wrong.

The main reason I use it is Lazy Loading and 2nd Level Cache. When you support systems that have several thousand concurrent users minimizing db hits is huge.

The first time I started using an ORMapper I couldnt believe how much better it was than writing sql and ado.net code. Then when I started using NHibernate I really could see the benefits. If you can't see the value it almost seems like you are doing something wrong. I look at it from an architecture and maintenance standpoint. The architecture of my applications are cleaner and I can create an object model that exposes my true intentions. I hate maintaning sprocs and data access code, so If I can eliminate the sprocs then Im much happier just maintaining hql or criteria api queries. Cant you see how much less code there is to maintain using Nhibernate?

I always wonder why people in the industry complain about learning another technology like NHibernate. Isn't learning new things what makes the job interesting and fun? What if people said that about asp.net and just stuck with asp because they already knew it and didnt want to bother with learning something else?

With all that said, NHibernate is not the holy grail. Its just another tool and should be used appropriately.

Unit of Work...getting this for free is huge.

I agree with mnichols. Unit of Work is a great reason in conjunction with an Identity Map. Anyone can write these patterns, but to create the flexibility needed between all the different projects takes a lot of work. NHibernate has already done all the hard work. Plus it is open source, so making changes to it is easy if you understand the patterns that were implemented to make it work.

However, NHibernate is not for everyone. If you are already using a tool that works for you and allows you to accomplish your goals within a reasonable amount of time, then the learning curve of another product may not be necessary. This is not to say you should not try and learn new things, but it would be added risk to learn these things in the middle of a project (especially one with a short deadline). You need to weigh the pros and cons. NHibernate is certainly worth learning, but no tool is worth the risk of losing a project.

HTH

If all NHibernate did was push and pull data in and out of the database, even with the caching, we would probably stick with basic code gen templates as well and save ouselves all the reflection (optimized though it is).

But we use NHibernate for the objects and 'polymorphic' queries. the thought of trying to come up with a code generator that gives you the flexibility of querying a rich and deep object hierarchy even half as powerful as NHibernate gives you for free makes my head spin.

For example, we currently have three types of assets in our system: files, posts (web entered text), and custom pages. At times, these all behave as Assets and we can query against our abstract Asset class in HQL and get a heterogenous enumerator of Assets back. Other times, we just need the Posts. On top of that, Asset is down a couple of levels in our hierarchy. The number of sprocs that we would need to generate and the logic needed to generate them scares me quite frankly.

But don't forget, always use the right tool for the job. If you don't see that you're getting benefit from the ORM, maybe it really isn't the right tool for you. It does have a bunch of overhead that would probably only hurt the performance of a small, data-in-data-out application with well tuned sprocs.