Azure DevOps, Scrum, & .NET Software Leadership and Consulting Services

Free course! Predicting the Future, Estimating, and Running Your Projects with Flow Metrics

Playing with NHibernate RC2

I’ve ignored NHibernate for much of the summer.  Lately I’ve been talking to potential clients, trying to drum up some business for Q4 and I’ve been surprised by how many questions I’ve gotten about NHibernate.  I’ve also been pleasantly surprised by the number of hits and emails I’ve gotten from random people in the NHibernate community since being listed on the nhibernate documentation page

I wouldn’t say that there’s going to be a rush to NHibernate but there’s good buzz around the upcoming “production“ release and when it comes out that there’s going to be plenty of companies who start giving it a serious look. 

Anyway, I’ve started pondering NHibernate again.  In one of my previous NHibernate posts, I wondered if it is worth the effort to learn.  The answer is still “it depends“ but with some new qualifications and ideas.  If you have a small project, you probably don’t need nhibernate…just stick with typed datasets, stored procedures, and a code generator.  On that size project you probably don’t need any kind of fancy object model because you probably don’t have much data validation, your data is probably simple, your data access is simple and bulletproof long-term maintainability probably isn’t (and shouldn’t be) a huge concern.   

For anything larger where you might actually want an entity-based object model (this is where I’ve started to come around again to nhibernate), how could you realistically do it except with an O/R mapping framework?  Solving the problem of taking an entity-based object model and turning it into relational data is going to be a nightmare.  You’ll end up writing something that has a billion lines of code to traverse your objects with tight coupling between your data access tier and your business entity tier — OR — you’ll write something that’s generic.  If you go the generic route, well, then you’ve got NHibernate. 

If you use the business entity model you have to solve the O/R problem, so why not use something that’s already there?  Why re-invent the wheel?  It’s open-source so you could presumably fix any bugs that come up.  Plus, it’s not like ObjectSpaces is coming any time soon and the future of LINQ seems a little fuzzy.  Plus, neither of those technologies will have been around the block as much as Hibernate and NHibernate. 

Also my mind has been cleared on two of the big things that made me skeptical of NHibernate:

Issue #1: Well, what if you want to use it in an SOA or webservice context and your entities have circular references in them (ex. parent-to-child with child-to-parent relationships)?  You’ll get XmlSerializer/SoapSerializer circular reference exceptions. 

Issue #1 resolved: This wasn’t ever really a problem with nhibernate…this is a limitation of the entity-based business model and the .net serializers.  In a discussion with Michael Stiefel (who I still owe lunch to) about SOA, he pointed out that trying to directly serialize the entities is a bad idea to begin with.  There needs to be some kind of adapter in the web service/SOA tier that converts the internal object model to something that is more XML friendly.  The internal object model isn’t necessarily a good model for the XML transport. 

Issue #2: If you have to do complex queries and joins for searches, then you’ll end up re-creating those structures in HQL and that’s a big pain and a big learning curve to accomplish something that could be readily done with SQL.  That’s stupid.  Why bother?

Issue #2 resolved: This one was resolved with input from Ben Scheirman.  Ben and I have had a multi-month, on-going discussion on nhibernate specifically around nhibernate session management in ASP.NET.  His solution came as kind of a dope slap.  Don’t bother trying to solve the problem with nhibernate at all.  Open up a database connection in the regular way, run the query BUT only retrieve the matching primary key values.  Then pass the keys off to nhibernate and let nhibernate work it’s retrieval magic.  To paraphrase, render unto SQL the things which are SQL’s, and unto NHibernate the things that are NHibernate’s. 

Other news… I refactored my NHibernate sample application a bit…mainly just cleaning up the interaction between BaseDataAccess and the HttpModule.  Nothing major.

Also, I’m working on creating a new and improved sample app with the RC2 of NHibernate and ASP.NET 2.0.  More to come.




One response to “Playing with NHibernate RC2”

  1. Greg Banister Avatar
    Greg Banister

    Re: Issue #2:

    Have you considered the ICriteria Interface and the Sesson.CreateCriteria?

    From the nHibernate doc "Criteria is a simplified API for retrieving entities by composing Expression objects. This is a very convenient approach for functionality like "search" screens where there is a variable number of conditions to be placed upon the result set."


    IList cats = session.CreateCriteria(typeof(Cat))

    .Add( Expression.Like("name", "Iz%") )

    .Add( Expression.Gt( "weight", minWeight ) )

    .AddOrder( Order.Asc("age") )


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.