Ayende @ Rahien

It's a girl

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

Comments

Ali Kheyrollahi
11/18/2011 10:28 AM by
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.

Wesley
11/18/2011 10:30 AM by
Wesley

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
11/18/2011 10:31 AM by
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
11/18/2011 11:55 AM by
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
11/18/2011 12:06 PM by
Billy Stack

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

Luiz Adilson Bon
11/18/2011 12:16 PM by
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.

Torkel
11/18/2011 01:27 PM by
Torkel

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.

Rafal
11/18/2011 01:55 PM by
Rafal

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.

Scooletz
11/18/2011 02:18 PM by
Scooletz

@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

SteveR
11/18/2011 03:28 PM by
SteveR

@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.

Rafal
11/18/2011 03:49 PM by
Rafal

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.

kibbled_bits
11/18/2011 04:01 PM by
kibbled_bits

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.

Rafal
11/18/2011 04:06 PM by
Rafal

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.

SteveR
11/18/2011 04:17 PM by
SteveR

@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.

LukeB
11/18/2011 05:26 PM by
LukeB

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
11/18/2011 07:42 PM by
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/

MarcoC
11/20/2011 01:45 PM by
MarcoC

@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.

Jeroen
11/20/2011 08:17 PM by
Jeroen

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
11/23/2011 02:32 PM by
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.

Ben
11/24/2011 02:27 PM by
Ben

Dude you change more than the wind

http://ayende.com/blog/4571/microsoft-data-because-the-90s-were-so-good-we-want-to-do-them-again

Comments have been closed on this topic.