FluentNHibernate vs. Code First in EF 4.1

First, having been in the SharePoint space exclusively for so long now, I have to admit: it’s been a while since I’ve had to deal with non-SharePoint data access.  I don’t know if I miss it or not 😀 I’ve become really comfortable with my little SharePoint ORM approach thingy that generates models and such from content types (before you say SPMetal, this was developed for 2007 and I think still works better than SPMetal).

In the past, I’ve mostly avoided Entity Framework (EF), preferring LINQ-to-SQL due to EF1’s shortcomings such as being less performant, creating more obtuse queries, my general disdain for the entity designer, the overly complex API, the lack of POCO support, etc.  I’ve also spent some time with NHibernate and FluentNHibernate and found it more pleasant to work with as an ORM solution.

Only recently have I discovered the “code first” approach released with EF4.1 which makes it much more appealing in the same way that FNH made NH more appealing by doing away with hbm.xml files for mapping your entities.  So I decided to take it for a spin and see how it measures up to NH+FNH.

If you’re interested in much more in depth (and partisan) debate on the merits of one or the other, there’s plenty to go around.  I won’t get into that 🙂 I’m just concerned with the basics for now and I anticipate this being a series of blog posts as I test the merits — and demerits — of each.

For this first post, the basics are:

  • Create a simple console application that manages contacts
  • The application should auto-generate and auto-provision the schema
  • Basic queries should just work and not generate “dumb” SQL (i.e. counts should use COUNT in SQL, basic paging should be SQL based).

First up: Entity Framework.

So let’s jump right into the code:

I like that it’s fairly compact and straightforward.  The development experience was a bit challenging, though.  First, EF doesn’t like it when you try to use the schema with an existing database.  It insists that you let it provision the database.  Okay, fine (though there are workarounds).  It’s often thrown around in these debates that one of the benefits of EF is that it’s “out-of-the-box” but in reality, at least with the code first bits, it’s anything but.  You have to download EF4.1 first and install it just like you would with NH+FNH (though certainly, that may change in the future).

The walkthrough on the ADO.NET team blog is also broken.  To get DbContext, you need to add a reference to EntityFramework.dll, not System.Data.Entity as posted in the blog.  Overall, I found the code to be more compact and easier to work with.  The one downside is the that one has to consistently update the class inheriting from DbContext as new entities are added.

Second up: NH+FNH:

Now lets take a look at code that does the same thing in NH:

It’s slightly more verbose, but not terribly so.  One note is that unlike the case with the ContactContext in EF, you won’t need to continually update a “registry” with new entity types.

For this basic scenario, it’s hard to say I prefer one over the other, but I’d have to give the edge to EF so far simply for the intangibles (read: Microsoft supported – in other words, it’ll be easier from a convincing-your-team-to-not-roll-your-own standpoint).

Comparing the SQL

Of course, the next step is to compare the SQL generated from each of these.

Let’s take a look at each query:

You can see that for the first, paged read, EF uses a straight SQL statement whereas NH uses a parameterized dynamic SQL statement.  For this small dataset, there is no discernible difference in performance, but I would gather that for larger datasets, we’d see a performance boost with NH.

For the second query to count, we see that again, there is a small difference in how the two go about generating queries:

As far as I can tell, for this basic scenario where there is no additional filtering on columns, there should be no practical performance difference between the two (though obviously, EF generates an extra nested select statement, the real world performance impact is negligible).

Next up: I want to do some more tests with more complex queries and figure out how each of these frameworks handles dealing with schema changes.  Seems like a wash for these basic scenarios and one of personal preference.

You may also like...

3 Responses

  1. Stuart says:

    Great article, just what I was after. Love to know when/if you do performance testing against larger & more complex datasets. I”m a BIG fan of EF4.1 and would prefer over NH.

    Cheers, Stu

  1. July 1, 2011

    […] I just recently posted a short write up on Fluent NHibernate vs. Code First in Enterprise Library 4.1. […]