NHibernate and Entity Framework Battle it Out in the Real World

The scene: a company division with no prior in-house experience using any ORM of any kind. A really, really legacy database-the kind with many composite keys, fields with mystery names, uneven use of enforced keys, etc. Currently, access done through ADO teamed with stored procs containing dynamic sql involving string concatenations (horrible for speed, security and my sanity among other things)

The mission? Given the constraint of not being able to change the underlying database aside from adding on some views, build a clean, modern app to eventually replace a legacy app that’s creating significant maintenance pain.

Early on, the team decided to lean toward use of an ORM-several team members had had positive past experience with ORMs, and it seems to be the way the industry was headed. However, that still left a choice-which ORM? The choice was quickly whittled down to NHibernate and Entity Framework. We ran two small parallel spikes, and ended up with a few thoughts about working with each:

First, we picked 3 or 4 tables to map to with both technologies, wrote up some simple classes, and then set about setting up persistence through an ORM-agnostic repository via both mappers.

NHibernate’s mapping files are relatively easy to read, but there’s no GUI to write them for you. It lets you write your classes and then work on your mappings separately afterward. The classes are clean POCO. NHibernate requires some code modification (virtual/overridable) and works better with some child-to-parent mappings that don’t seem like they should need to be there, but generally, modifications needed are minor. Repository is straightforward, and there’s lots of helper code online to do the legwork. Not tested, but it’s got sophisticated caching built-in.

Entity Framework was from Microsoft and had a GUI. The classes were autogenerated in one direction, from the database to the GUI to the classes… non-mapped properties caused errors-the proper place to put such artifacts was in a separate partial class file for the class-looking at the autogenned class, it was VERY clear you were not supposed to touch it, and probably not supposed to look at it.. this left the class spread across your partial and the gui. In addition, there were tight EF dependencies on these domain objects. Not to mention, after working with the GUI, I got the strong feeling that the GUI would not be able to handle complex scenarios, leaving us working with the raw verbose and complicated (and not really designed to be hand-edited) mapping xml. A pre-written class doesn’t seem to be able to be used easily-at least, we were exploring the usefullness of the gui, which left us to recreating the pre-written classes via the gui. It wasn’t clear if it was possible to mark a class as read-only, and code wouldn’t even compile if fields required in the DB were not mapped. Repository pattern was a bit more work-less guidance online… not sure if that’s because EF is so incredibly new, or because EF users are generally not as familiar with this pattern… in any case, it was a bit more tweaking to get things working through a moderately ORM-agnostic repository interface. No seamless caching yet-that’s slated for v2.

Non-technical factors:

NHibernate was an industry leader, was fairly mature, had been around a few years (and a few MORE years if you counted Hibernate) and a team member (me) had experience using it in a high-profile production environment. No paid support available to speak of (not counting unknown companies here) but a truly responsive, helpful community with a product that is in active development… but then, NO backing company (not even Red Hat these days) … potential of giving fly-by-night appearance to non-techies as a result.

Entity Framework is brand-spanking new. If it were a car, it might still have temporary plates! It’s a 1.0 Microsoft product, with all that implies. Next version slated for 2010. If anything happens, Microsoft’s there for help, or (worst case) to receive a lawsuit. And it’s always easy to justify a Microsoft product.

It was a tough debate, but we ended up going with Entity Framework. Despite agreeing that NHibernate was the better technical solution, the team eventually concluded that having a backing company was extremely valuable for the organization, and that the GUI would be helpful for people coming into the project that were unfamiliar with ORMs.

The next morning, we set about doing some preliminary mapping. (ignore the DDD-related problems with this workflow for now, please)

  • Yeah, that GUI is looking even more inadequate…
  • Generated class and mapping files are THOUSANDS of lines long-this really sucks what with the inadequate GUI
  • IT was REALLY easy to screw up the EF stuff so the gui couldn’t load-easiest way to deal was to redo the whole thing-I think we did that about 5 times that morning.
  • It didn’t seem to deal well with the messy legacy db. Due to the db-first nature of EF, the messiness was going to leak through into our classes…
  • We were going to be on the hook to support this thing-were we ready to do that?

By noon, we’d decided to switch to NHibernate. Cleaner code, clearer classes, and a team member with experience suddenly became a whole lot more compelling.

Working through those mappings has been a valuable, revealing process too. (more on that in a later post)

(Corrected: Thanks to Scott Bellware for the heads-up that even if you’re working on a VB project, it’s still POCO and not POVO, since the C stands for CLR, not C#.)

Tags: ,

14 Responses to “NHibernate and Entity Framework Battle it Out in the Real World”

  1. That was almost the exact experience of my team in taking EF for a spin. Unfortunately, I kept the team trying for two months – wasting much more money than you did.

    Anyway… good call. I don’t believe that you’ll regret your decision in the end. The knowledge and experience in building apps on .NET with contemporary approaches combined with ORM is squarely in the NHibernate community.

    If you spend some time on the EF forum you’ll start to see that the EF community is barely at the level of knowledge, expertise, or responsiveness that the NH community was at four years ago. There’s no question that NH far out-performs EF in both maturity and support.

    It’s not like you can call up Microsoft Premium Support to find out how to use EF to model some aspect of your app, anyway. The kind of support you need for an ORM is often more contextual and situational, and your best options there are either going to be a vibrant, mature, responsive community, or a consultant. In the NH world you have both, and both the community and the consulting resources have years of seasoning rather than mere months as is the case with EF. Not to mention that the baseline quality of the software people in the NH space is way beyond the EF community and will likely remain so for several years.

  2. Rod says:

    Interesting post; a lot of teams that got all excited with the easy of use brought by Linq-to-SQL just to be let down by Microsoft might be going through the same process right now. I noticed that you didn’t even mention L2S, I wonder why? Not ORM enough? Hard to make POCO classes with it? Microsoft dropping it? All of the above?

  3. ajepst says:

    Rod, Microsoft’s dropping Linq to SQL was a factor, though we had already decided we’d primarily focus on full ORMs. In fact, though I neglected to mention it above, Microsoft’s clear message that EF was the company-recommended way to do data access going forward was a notable point for EF specifically, but also a big point for the ORM approach as a whole- In a year or two, the ORM concept should be familiar and comfortable to most .Net developers, and discussions at that point should hopefully be centered on relative merits of different ORMS instead of why an ORM is better than plain old ADO hand coding.

  4. Phantom says:

    I have faced similar objections when recommending NHibernate. It seems that people conclude that using an open source product vs a “supported product” from Microsoft is best.

    I am currently working with a team of developers where one of them “Loves!!!” to use datasets as the business layer. I gotta tell you, this guy knows datasets inside out and he can do anything he wants with them, but he always has to start a solution design with an ERD and the finished solution is tightly coupled with the database and he has a hard time solving problems in business terms that are not database related.

    When I walk into a project one of the things that I dislike is that there is always somebody that created golden rules such as “All calls to the database need to be with a stored procedure”

  5. Dmitri says:

    What did it for me was the fact that Entity Framework didn’t auto-generate proxy methods for my stored procedures. Linq2SQL does it just fine, so why not EF? Also the UI support for EF in VS is really not good enough – just try adding a foreign key _after_ you’ve created the model, and you’ll find that you have to delete the reference field manually, even after updating the model via the wizard.

    Right now, I’m leaning heavily towards FluentNHibernate. My guess is anyone looking for an ORM now really has no choice. When VS2010 and the new EF comes out, well, we shall see. For new projects EF might be suitable then, but I doubt existing ones will go from NH to EF.

  6. Arash says:

    Look at Mindscape’s LightSpeed product. It’s a very easy to use ORM with full LINQ support, meaning your LINQ query will be translated into an appropriate SQL query. I don’t think NHIbernate has that yet.

  7. Juan says:

    Hi everybody. We had to make a choice some months ago, regarding the ORM mapping framework for our new project, it had around some 100 tables. Well, we tested like some 6 ORMs!, including EF. The fear we had with third party ORMs was that you leave something very importante in some other’s hand and the possibility that the product could become obsolet due to a not more supported or bad supported product.
    Our EF team did a great job in our detached scenario using WCFs and EF in both client & server sides. After two months of hard work we made everything work fine using a special class for attaching detached entities

    (http://www.codeproject.com/KB/architecture/attachobjectgraph.aspx)

    now we have a faster development process due to sepparating our UI and BO layers from client to wcf server and created a generic Client service layer and WCF service layer for any kind of project, so we just add some dlls references and the communication channel is done!

    well, what else I can say. after some hard work, using .net 3.5, we are using EF in a detached scenario very elegantly (not using mar property as modified, hehe).

  8. Interesting blogs. Our development team must make the decision with VS2010, Nhibernate advise using?

  9. Piglet says:

    A tip: Before making a decision Nhibernate or Entity Framework 4.0 read this post (with ALL its comments). It sure helped me:

    http://ayende.com/Blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

  10. A lot has changed since you first wrote this post! Anyway, Nhibernate now has a GUI designer which helps you create and maintain NHibernate projects: http://www.slyce.com Pity it wasn’t around when your project started!

  11. […] vs Entity Framework: http://foofish.org/blog/?p=57NHibernate vs Entity Framework performance test: […]

  12. Mike says:

    I’m with Piglet: If you re-investigate the comparison nowdays you will find that Entity framework has come a long way since this article was initially published. Nhibernate has improved too, but it’s hard for new ORM users to justify the learning curve when EF does a similar job out of the box and with better documentation.

  13. Sergey says:

    Interesting experience.
    I found that this article is the most helpful to comapre EF 4 to nHiberante:
    http://xhalent.wordpress.com/2011/02/01/nhibernate-vs-entityframework-experience-from-the-real-world/#comment-158

    There is one more point for consideration when choosing EF vs. nHibernate: EF can query SSAS OLAP cubes ( via SSAS Entity Framework Provider – http://www.agiledesignllc.com/Products ), and nHibernate cannot. It is important if you have large data volume (> 2 million of records) but still need your queries to execute very fast.

  14. Pope Joan says:

    Hey there! I’ve been reading your web site for a long time now and finally got the bravery to go ahead and give you a shout out from Houston Texas! Just wanted to tell you keep up the good work!

Leave a Reply

WP-SpamFree by Pole Position Marketing