Not that into NHibernate

I heard great things about Java's Hibernate, so I checked out NHibernate (Hibernate for .NET). After researching it a bit, I believe it will take more time and hassle to maintain than the current way I map data to objects. Here are my reasons.

Maintenance - 3 Sets of things to maintain

1. C# Objects
2. XML Mappings (something extra to learn)
3. Database relations

Maintaining the XML doesn't have to be tedious, since there are tools that can generate it for you from the database schema. But most of the projects I work on are constantly evolving, and data changes are frequent. Assuming I remember to do it, that's a lot of regenerating XML (the same reason I stayed away from typed datasets) in addition to changing C# objects and database structures.

There are also things like NHibernate Mapping Attributes and ActiveRecord. These allow you to forego XML at first (although they ultimately recommend making XML files). But instead of learning XML, you have to learn the appropriate Attribute tags (although admittedly much less pain than the XML, especially ActiveRecord). Fluent NHibernate actually seems like the least pain, but you have to learn and use Fluent's coding conventions (which don't seem out of line) in order to get it to work properly.

Database Independence

This is probably the thing that NHibernate has going for it most. If you use the query language and the criteria language to get all your results, then you really could be connecting to just about any database.

The main issue I have with this is that NHibernate queries != stored procedure calls. For small projects that you don't expect to grow, stored procedures could be an overkill (but so could NHibernate!), but for projects of any complexity store procedures are the way to go. Stored procedure calls have a couple of major advantages, not the least of which being the object-oriented principle of encapsulation (or information hiding if you prefer). If you have a DBA, they can completely rewrite a procedure (for efficiency, say) and your program never knows the difference, which is a Good Thing. The other major advantage is performance as database procedures can be pseudo-compiled, depending on db platform, to make them run faster.

You can use NHibernate to call stored procedures, but the XML just specifies the native stored procedure call syntax ("exec proc_name" in MS SQL and "call proc_name()" in MySQL, for instance) -- there's no real database abstraction advantage there. Worse, if you need to run a procedure that doesn't return a result set, then you just have to make a native query call.

Conclusions

While I had high hopes for using NHibernate to make data access easier, it doesn't seem to accomplish that goal for me. It's an extra thing to learn and maintain, and has a number of drawbacks. Next article (who knows when that will be), I will show the way I architect data access. It might be a laughable thing to some of you (as if anyone reads my blog), but it's the easiest way I've found so far, while still having a lot of flexibility.