NHibernate - Should I use it?

[Jaws]

On a project I recently left from, where we used a similar approach above, they got in a set of JAVA guys who were going to build the same system from scratch, but in JAVA/Hibernate/etc instead of C#. Guess what! They're having MAJOR performance problems, because they're not really sure how there application code is calling the database.

So, in summary, hand-code it and be sure of what's going on under the hood.

Just my 2p...

While I agree in some respects, I think this problem may be more down to the developers not taking the time to read about NHibernate (ie books) than anything else.

My personal approach to O/RM recently has been using code generation tools driven by an xml file to produce the relevent data mapping code and stored procedures (some of which returning multiple result sets when a list is not configured for lazy loading). Given the chance I would have used NHibernate or another framework but the client is not happy about using external components.

[BamBam]

Here's my take on any object relational mapping tools...

Can you still monitor what's going on "under the hood"?

I've looked into this quite a bit recently, and IMHO, when you create the objects yourself, you can fully control what's going on with your data access. For example, if you have a set of complex queries going on to return some data (ie you want to eventually have an object that has several sub-components/objects, and the database is very normalised), you might end up with several calls going back and forth to the database.

A good approach I've been using/tweaking for the last couple of years is to do all the complex data work in a stored proc, returning the data back in a structured XML document. The benefits of this are:
1) You take advantage of the performance advantage of stored procedures
2) You can structure the returned data (using XML) from within the stored proc, making it easier to translate this to a set of objects within your application code
3) You can control database access directly and in a better way, because you can easily set access permissions to a storedproc using "grant" for a specific user
4) you can easily test your stored proc with different parameters and examine the returned XML results

Now, in your code, the Business Object layer can call your Data Access layer which will call the stored proc in the database and get a resulting XML document. Your BOL can then process this XML and create the desired object/s.

On a project I recently left from, where we used a similar approach above, they got in a set of JAVA guys who were going to build the same system from scratch, but in JAVA/Hibernate/etc instead of C#. Guess what! They're having MAJOR performance problems, because they're not really sure how there application code is calling the database.

So, in summary, hand-code it and be sure of what's going on under the hood.

Just my 2p...

[Jaws]

Another thing to bear in mind is that it's far easier to use if you are not forced down the stored procedure route.

[HairyArsedBloke]

If you're an experienced developer ...

Ah

It is not best to have to apply it to an existing database schema and application though! It's much easier for a greenfield project.

Oh dear.

[jkoder]

Somehow I’ve allowed myself to be talked into using NHibernate on a web project. It is something that I know nothing about, but I know the current way the application works needs to change.

There is not really any transactional or large scale issues to face. The only non-trial issue is that there will be a number of accesses that return time series data (between 30 and 1000 points).

• Does it take long to learn?
• Is it difficult to diagnose problems when things go titsup?
• Has anyone got any idea if I’ve made a big mistake?
• Has AndyW led me astray or should I have outsourced it all to Bob Shawadiwadi?

Based on using Hibernate/Java:

If you're an experienced developer you can learn a lot about Hibernate in a single day, certainly enough to get going. You will run into snags here and there and It has a few gotchas like any other framework. You should have a look for IDE plugins which generate code for you based on your maping file.

It is not best to have to apply it to an existing database schema and application though! It's much easier for a greenfield project.

There is lots of information online and I would stress learning about sessions , transactions, configuration and mapping before diving in. You should be able to spend half a day learning how it works and seeing if it's going to be worthwhile using it in your application.

[Mehmeh]

nHibernate is awesome, not hard to learn at all...

it can be annoying creating all the xml files if you have massive database though.

nHibernate is really good...but if your not sold completely on it yet consider subsonic, it saves all the creation of xml files and if you already have your db youll have the data layer done in like 2 minutes. It uses the active record pattern.

http://subsonicproject.com/

I use ORM tools as much as possible now...sod writing dals by hand anymore!

[HairyArsedBloke]

Somehow I’ve allowed myself to be talked into using NHibernate on a web project. It is something that I know nothing about, but I know the current way the application works needs to change.

There is not really any transactional or large scale issues to face. The only non-trial issue is that there will be a number of accesses that return time series data (between 30 and 1000 points).

• Does it take long to learn?
• Is it difficult to diagnose problems when things go titsup?
• Has anyone got any idea if I’ve made a big mistake?
• Has AndyW led me astray or should I have outsourced it all to Bob Shawadiwadi?