Ok. So. I’ve been playing with the object relational mapping framework called NHibernate for a while now.
I’m pretty conflicted about it. It’s definitely cool and it has a lot of great features (most of them I’m probably not even aware of yet).
If you’re doing .NET development, it’s pretty much a given that you know ADO.NET and probably 99.9% of .NET shops use ADO.NET. Even if you’re not a database expert, doing basic CRUD operation with ADO.NET is pretty easy and even if you don’t know how to do it, there are 4000 books out there that’ll teach it to you it in about 2 pages.
And then there’s NHibernate. If your architecture goes heavy on business entities and light on DataSets, NHibernate solves your sticky data access problems. You set up your O/R xml mappings and you’re pretty much good to go. Where it gets sticky is when you have to start doing custom queries against the db. Example, give me all the users that aren’t associated to the a customer who have been created in the last year. NHibernate will do that for you. The problem is that you’ve got to learn the NHibernate syntax and that syntax is definitely different. If you know database programming, you’re going to get pretty frustrated trying to figure this out the first time you want to do it.
And that’s where I start to see a big downside to NHibernate. It’s just another technology for someone to learn in order to get their work done.
From a nerd’s perspective: It’s cool. It’s nifty. It’s a new way to do stuff in .NET. Hell…it might even let you write more elegant code.
From a company’s perspective: It’s just more stuff to worry about supporting. You can’t hire your average .NET programmer off the street because he/she very likely has never HEARD of NHibernate let alone actually worked with it enough to maintain a company’s code base.
The jury’s still out. [Update 12/10/2005: The jury came back in early October. Here’s the update
-Ben
Leave a Reply