NHibernate O/R Question

Question

I have written a lot of ejb, oledb and ADO code over the years. My experience with O/R mappers is at best they are pigs for speed, at worst a bug filled nightmare.

Is NHibernate or Spring .NET worth the trouble and why?

Answer 1

They are worth the "trouble" because they let you clearly define your data in a model that is separated from behavior and other code. You don't need to write a custom DAL. They help with separation of concerns.

Answer 2

It depends on your focus, I guess.

In my shop, some people love 'em (the real Java/OO propellor heads) and some people despise them (with more SQL skills).

I'm in the 2nd group but I'm a developer DBA.

They're not evil, per se, but simply a useful tool if used correctly without any religous baggage.

Answer 3

If you don't mind a tight coupling to SQL Server and a relatively tight coupling to the schema, you might consider looking into LINQ to SQL. It's part of the framework, pretty straightforward, and amazingly easy to program against. You can be up and running and coding against it in minutes using the designer that comes with VS 2008.

That said, LINQ to SQL isn't the be-all-end-all; NHibernate is certainly more robust in many ways, and there's also the whole Entity Framework migration going on.

But LINQ to SQL is not a bear for speed. And I can tell you from experience that although the designer isn't exactly bug-free it is pretty robust and the underlying fundamentals are not buggy in the least.

LINQ to SQL is actually quite a powerful and mature ORM.

If you need a working example of the power of LINQ to SQL, take a look at this very website. It uses LINQ to SQL for the back-end, and I don't think it's slow at all.

Answer 4

I have not used the Spring.Net Data module, so I wont comment on that. I have used Spring.Net for it's IOC. In general, I think you can do better for that one.

NHibernate is very good. It will be slower than straight up ADO.Net, but in general, not enough for you to worry about. The key is that NHibernate allows you to get the database code up and running quickly, so you can worry about the actual application code. You application is more than the database.

Then when you find a query that is taking to long, and affecting application performance, rewrite THAT method using the traditional approach.

There are other alternatives as well, Entity Framework, SubSonic, LLBLGen, etc.

Answer 5

As Matt mentioned ORMs are valuable for the separation of concerns they allow in your application design. The big tradeoff of course is raw performance. The philosophy I suppose is that you can always scale your hardware resources, but you can't easily scale and extend tightly coupled code.

If you're looking in the .net space, give some consideration to Lightspeed. It's a commercial ORM, but significantly faster than NHibernate, and generally more intuitive to work with.

Answer 6

NHibernate is definately worth the effort. As others have said, it is slower than directly using ADO.Net etc, but the increase in productivity is worth it I think. On the performance front, there are quite a few tweaks you can do in NHibernate to speed things up:

1. Lazy Loading - only load child objects/collections from the DB when they are actually requested
2. Caching - NHibernate has 1st and 2nd level caching. 1st level cache is used by default and means NHibernate won't run identical queries multiple times within the same session. 2nd level cache is down to the user, where you can choose which operations are cacheable (by a 3rd party caching engine), which NHibernate will handle for you. E.g. if you load an object many times over (across all sessions), and the object changes rarely, making it cacheable to speed things up.