When to use NHibernate

Ayende posted some guidance on when to use NHibernate:

If you are using a relational database, and you are going to do writes, you want to use NHibernate.

If all you are doing are reads, you don’t need NHibernate, you can use something like Massive instead, and it would probably be easier. But when you have read & writes on a relational database, NHibernate is going to be a better choice.

That’s pretty much mirroring my experience lately, although I’m starting to have a higher bar for the writes. If your database actually has relationships enforced by constraints on writes, that’s when I feel that NHibernate is useful. Otherwise, we’re starting to use things like Simple.Data, Massive, PetaPoco etc. for reads and writes.

For CRUD kinds of systems, where you don’t really have relationships, it’s much easier to go the Micro-ORM route, where you’re just trying to get from SQL to POCO as quickly and easily as possible.

However, if you do have relationships that you want to model in code, that pretty much immediately starts to require NHibernate. But, if you draw your DDD bounded contexts well, you’ll find you need a lot less Big Bad Frameworks to get things done.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in DomainDrivenDesign. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Bogdan Marian

    How many times have you stumbled upon a real application using a RDBMS, but with no relations? In such a case,  were they enforced at application level?

    • Anonymous

      Just pushed one to production last week, and I have a couple in production that are supporting millions of users. You find it more and more in CQRS/DDD scenarios, or in the micro-site scenarios. But there’s definitely a big middle area there.

      • Bogdan Marian

        Ok, but why use then a “relational” DBMS? Why not using a key-value store or big table? 

        • Anonymous

          A lot of times we’re constrained on what our hosting provider allows. But, a lot of the times we don’t even consider options (when we probably should)

  • Steve Sheldon

    A few of my fellow developers were talking about this a few months back, mainly in relation to EF, but NHibernate offers the same puzzle.  We like the ORM for mapping out an aggregate root and it’s various entities, values, etc. for retrieval and then the change tracking for updates.

    What we don’t like is the query language.   LINQ or other, the reality is that there is a great DSL out there that is very expressive, well known, and readable and it’s called SQL.  So just using a micro-ORM seems really appealing in this scenario.

    The biggest problem with that division of responsibility is the data schema, and that’s when the CQRS pattern starts to come into play because it segregates that between reads and writes.  But then you start questioning why you have a write schema that is relational…   Or even a read schema that is relational.

    So I’m looking forward to Ayende’s next post. :-)

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #985()

  • The thing I dislike about Massive is that there are NO tests in the project! https://github.com/robconery/massive

  • Joe

    Any advice on using some of these micro-orms in the DDD, Bounded Context arena? We us NH, quite a bit, but we have started looking for “simpler” options in the micro-orm space, but are hitting some walls when looking at Bounded Contexts and Aggregate Roots.

    • jbogard

      What sorts of walls?

      • Joe

        It seems to come from the lack of cascading saves and lazy loading.

        For example, take an Order that has multiple OrderItems. We define an aggregate that just contains these to objects. The aggregate root, Order that has a collection of OrderItems, through the root we can add and remove items as needed, then we can save that root and have both the Order and its OrderItems persisted. So we have nice neat POCO objects. Using a micro-orm we fall back to a repository pattern or we put persistence in the Order via a “Save” method that would coordinate the persistence, but this gets away from the POCO style objects.

        The only time I have seen aggregates modeled with persistence used the “big database frameworks” such as NH or EF or document databases like RavenDB.
        So if you had some secrets on doing the same with a micro-orm I was hoping you may share them. :D

        • jbogard

          Nope, you’re pretty much stuck with an actual ORM or a doc DB. But I don’t think that’s too horrible, if you need advanced features, you’ll need a full-featured tool.

  • Taz

    Interesting discussion.

    I had to evaluate ORM’s for my company over a year back and in the end we ended up using LLBLGen Pro. We have one nHibernate guy who seems to hate it but everyone else likes it :)

    • Mazhar

      Well nhibernate can be a real pain so no wonder if he hates it. I am myself working in a team where we use nhibernate and I hate it. Its very complex and learning curve is very steep. Nhibernate is not an easy and quick option to get your DAL done. it needs certain skills and time to master it so in most cases its better to avoid it and better choose something simple.

      • jbogard

        I agree. Depending on the length of the project, I’ll start with something simple like PetaPoco. I still don’t really start with EF though, since it’s also a large, complex ORM.