Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,130 | Comments: 45,558

filter by tags archive

When should you use NHibernate?

time to read 1 min | 78 words

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 said, look for the next post about when you should be using a relational database.


Ali Kheyrollahi

Not my cuppa tea mate. Using NHibernate in RDBM is like gardening with a crane where all you need is a pair of scissors...

I have taken out all my NHibernate and now using Simple.Data.


Really? That simple? From my experience. If you want to do simple CRUD you use an ORM mapper to save dev time. So any ORM mapper will do. If you do more complex things in DB or need high performance you better use manual ADO.NET or something like Dapper to do reads.

But this is/can be a long discussion with pro and cons.

Phil Jones

Prefer Simple.Data when working with SQL Server.

But I suspect my negative view of heavy weight ORMs are due to the ridiculous levels of abstraction people insist on using with them.

Ronnie Overby

You didn't say why this is so. Also, are you talking about when to use a fully featured ORM vs Micro ORM, or are you saying there is no situation that warrants using Entity Framework or one of the others? By the way, my micro ORM of choice right now is PetaPoco.

Billy Stack

If using an append only model in a RDBMS, why would you use NHibernate?

Luiz Adilson Bon

In my last project I used nHibernate to manipulate all database functions and to make reports I've used Massive and stored procedures from SQL Server. It worked very well for me.


This is pretty much my recommendation also, If you want to have complex domain models, use an ORM like NHibernate to handle writes. Then have separate read models that are fetch through simpler means.


Torkel, if you have invested a lot of time to build NHibernate mapping for your complex model, why not use that model for reading data as well? I don't see your point in using something simpler for reading - it is simpler but not free, will require additional testing and development so the total cost is greater than when using NHibernate alone.


@Rafal Agreed. Having all the fetching, criteria, query cache etc. after you mapped domain is nice. If you really bother some simple queries' performance, then you should consider switching to sth lighter


@Rafal It's simple separation of concerns: your domain model is for implementing domain logic that for the vast majority of the time only comes into play when you want to mutate the state of the domain in some way (and subsequently save it). Your needs for the read side are often very different and can be better served by a different, read-only model. Trying to shoe-horn those two different concerns into the same model can end up not serving either purpose well.

CQRS and DDD's idea of Bounded Contexts suggest that this approach supports better scalability and clearer, more easily understood models. So there's an argument to be made on the gains from doing things this way to offset the extra work that it may take to implement it. With Dapper, Massive and Simple.Data the read models can just be dynamic expando objects so there's not much extra work there anyway.


Guys, I never said ORM is good for reporting or bulk data processing. But it's reasonably good at reading data if the number of rows is not too big - say no more than few hundred. If you are reading 100 rows it doesn't matter what ORM are you using or if you're using ORM at all - the database performance is what matters here and if your query is slow you should start with optimizing the db index, not throwing away the ORM. And please don't add CQRS into the mix because it's not relevant here - separating read and write operations doesn't mean you can't use the same tool for reading and writing.


Ayende is saying when you really should be using it, not when you shouldn't. You could really use it well for reads because IMHO NHibernate's ability to adapt to any RDBMS optimally is better and more abstract that every other implementation I've seen.

NHibernate supports batching gives you a lot more power if you are doing something like ETL.


Continuing my comment above: Currently (I mean today) I'm implementing a search solution for an OLTP application that uses SQL Server and relies exclusively on an ORM for data access. And the search is based on Apache SOLR server and a full-text index external to the RDBMS. I made a decision to replace SQL search with SOLR not because the ORM was bad but because SQL search capabilities and performance did not satisfy user's needs. ORM will be still used for reading the data from the RDBMS but SOLR will handle all filtering and I'll say it again - ORM was never guilty of degrading the search performance.

BTW I'm working on a quite interesting concept of storing JSON documents in the SQL Server database and outsourcing the search to a SOLR server. This is something like RavenDB built on top of SQL Server storage (but I will not be turning this into a competing product, at least for now :). We could, however, do some performance comparison.


@Rafal When someone says they're using different models for read and write side as Torkel did, CQRS and Bounded Contexts are very much relevant to the discussion. You originally said "why not use that model for reading data as well?" implying using the same model not just the same tool, and I answered. Nobody said anything about "throwing away the ORM" either, BTW.


Interesting advice. Based on my experience, I would give the following recommendation:

If your entities interact and modify each other and/or you must track changes across more than one or two entities per unit of work, then use an ORM. Otherwise, for anemic domain models in basic CRUD scenarios, an ORM is probably more trouble than it is worth.

Demis Bellot

There's a lot of other great .Net Micro Orms over at: http://code.google.com/p/dapper-dot-net/

Each have their own unique features and strengths. A good summary of most of them is at: http://yobriefca.se/blog/2011/06/21/microorms-for-dotnet-inserts-updates-deletes/


@Ali I'd say that using ADO to do CRUD in a RDBMS with many tables is like to harvest a large crop with a pair of scissors: perhaps your wheat is better cutted, but who cares ? You really need an harvester.

When should you use NHibernate ? When you must do CRUD with complex model (I'd say more than > 50 entities it's enough) and you don't have the money to afford the development of an handmade solution. Some years ago ORM has been like a silver bullet to let you deliver large and complex solutions at affordable prices, with just a little penalty in performance in certain situations, now it has become a must use, or your software if going too cost way too much.


ORMs exist because of the impedance mismatch (http://en.wikipedia.org/wiki/Object-relationalimpedancemismatch). If you suffer from this, use an ORM. If you don't (e.g. data-driven application), then there is no reason to use one.

Eric Ghent

To Ali Kheyrollahi's comment about Simple.Data. I've used Simple.Data on several projects, and think is great for small simple Active Record type web pages. I still found my self using WebMatrix.data for some tasks. I'd hate to use it for applications of any size, especially where I have a larger team and large business logic requirements. Now I'm using RavenDB for as much work as possible and it's great. Also, Simple.data does not do search well.


Dude you change more than the wind


Comment preview

Comments have been closed on this topic.


  1. How to waste CPU and kill your disk by scaling 100 million inefficiently - 7 hours from now
  2. RavenDB Conference 2016–Slides - about one day from now

There are posts all the way to Jun 01, 2016


  1. The design of RavenDB 4.0 (14):
    26 May 2016 - The client side
  2. RavenDB 3.5 whirl wind tour (14):
    25 May 2016 - Got anything to declare, ya smuggler?
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats