Last week while teaching my new LINQ and Entity Framework course I got a question asking me to compare EF4 with NHibernate. Not having worked extensively with NHibernate, I wasn’t in a position to address the question. Then yesterday I received an email containing a link to a blog post by Oren Eini (aka Ayende Rahien) doing just such a comparison. Because Ayende comes from the NHibernate camp, I thought it would be interesting to highlight some EF4 capabilities lacking in the current version of NHibernate.
- EF is more than an ORM and supports a streaming model with data readers against the entity model without materializing entities
- EF supports LINQ out of the box (NH doesn’t have it yet)
- EF has a good designer (NH doesn’t)
- EF has much better documentation
- EF has an end-to-end n-tier solution out of the box with Self-Tracking Entities (nothing like that for NH)
- WCF Data Services (Astoria) integrates well with EF
On the other side, NH is a much a more mature ORM product than EF and has better batching capabilities. It is also more extensible, especially as an open-source product. That said, EF also has extensibility points, as evidenced by the EF Extensions project, which enables processing of multiple result sets from stored procedures. EF also allows you to define functions with Entity SQL that are embedded in the entity model, and you can execute queries and commands directly against the database, effectively doing an end-run around EF while mapping the results to entities.
Ayende mentions that NH will add LINQ with version 3.0, as well as better documentation, and I’m confident that EF will fold in features from NH in future releases. The end result will be greater parity between the two products going forward, making the choice even more challenging and determined mostly by philosophical and strategic factors.
Tony Sneed's Blog 
You forgot one thing: NH has performance problems, especially with updates, which are painfully slow.
And I doubt that this will change in 3.0.
@Tony: Nice post, however I think that you underestimate the maturity of NH. They have the maturity of Hibernate under their belt plus 6 or so years out in the wild. This has made it superior when it comes to modeling scenarios, performance tweaking, persistence optimization etc, etc. EF strong point is the LINQ support and the MS support and in v 4 it has been improved a lot, but the feature set of NH is just mind blowing.
Also you /can/ extend EF, but it’s very very hard. Read ayende’s posts about the subject. While NH as really good support (take a look at NH search for instance).
@Robert: Funny, in our current project we update 10 000 rows in a standard scenario (some go up higher) and the performance is great compared to Linq To Sql and even to handwritten T-SQL. It’s all about understanding how NHibernate handles updates and tweak the mapping for your scenario.
@Patrik: What do you mean by “we update 10 000 rows”?
This says nothing. 10 000 rows per year? month? week? day? hour? minute? second?
@Robert:
Patrik actually provides more information than your vague statement that NHibernate is “painfully slow”. Anyone can say that “Technology X” is slow, but it is nothing more than conjecture without some form of data to support your claim.
What does “painfully slow” mean?
I am not sure what “more than an ORM” means. I think it means that EF integrates with the MS stack well. So does NHib, so I am not sure how that is a benefit.
You can get Linq support for NHib out of the box as well. Sadly, it’s not 100% yet. But it works for 90% of cases I have used it for.
NHib also has designers, Visual NHibernate (http://www.slyce.com) for instance. Or CodeSmith or Genwise. Or just use Fluent NHibernate and let it do the mapping for you at runtime.
My copy of NHibernate in Action works as a great manual. http://www.manning.com/kuate/
What does “end-to-end n-tier solution” mean? NHib doesn’t need self tracking entities. Read up on Ayende’s blog to find out why.
I don’t have much to say about WCF services. You shouldn’t put your domain entities on the wire to begin with, so..
So basically your 6 items are mostly marketing speak, fluff and FUD.
Let me see if I can respond to each comment. Looks like diving into a hornet’s nest is a good way to get comments on my blog! 🙂
@Robert and @Jeff: I didn’t mention performance comparisons between EF and NH, although there are some out there (such as http://gregdoesit.com/2009/08/nhibernate-vs-entity-framework-%E2%80%93-a-revised-performance-comparison). A lot of it depends on what you’re doing, and there are some optimizations available (for ex, compiled queries and views for EF) and the ability to batch commands, which EF doesn’t currently support.
@Patrik: I’ll be the first one to admit that in many ways NH is miles ahead of EF, even the new version, which the EF team also readily admits: http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx. The purpose of my post is to point out some areas where EF stands out (LINQ, Streaming, Docs, N-Tier, REST). That doesn’t mean that EF is “better” than NH, just different.
Regarding EF extensibility, would you be so kind as to give me the specific post where Ayende discusses this topic? There’s no search function on his blog. Thanks!
@NotMyself: Let me explain what I mean by “more than an ORM,” because this is a key difference between EF and various ORM products such as NH. EF is an implementation of the Entity Data Model, which is based on Peter Chen’s Entity Relationship Model, an abstraction layer that represents entities and relations in a non-database-centric fashion. In terms of EF, you can query the EDM without using objects at all. This allows you to get an abstraction from the database but use a streaming approach with data readers. MS plans to bake this aspect of EF into other products and the key behind the integration with REST-based services ala Astoria
Thanks for the info on Visual NHibernate, although EF’s comes out of the box for free. CodeSmith is a code-gen tool, which I’ve used and like very much. The EF visual designer controls the mapping of the conceptual model, which you can access without the ORM component (as I mentioned).
Regarding self-tracking entities, I’d like to get a reference to the post from Ayende you’re referring to. It would be great to know how STEs are implemented by NH. The purpose of STEs is to allow you to serialize tracking info so that changes can be persisted by a remote service in one batch / transaction.
Cheers,
Tony
This might be the article they’re referring to.
http://ayende.com/Blog/archive/2010/01/13/designing-the-entity-framework-2nd-level-cache.aspx
I read your excellent article on the N.tier Entity Framework support and the Self Tracking Entities. It is excellent.
I do have a question. When I get in the client and add the proxy. I will like to have a Dataset that I will drag and drop on the form and also put a binding navigation Component.
In my case I have many tables that I need simple navigation and updates and I will like to transform my application using WCF and EF4.
Thanks in Advance, from Dominican Republic.
Hello Pablo,
Sorry it’s taken awhile to respond . There’s no need in Visual Studio to use Datasets for data binding. You get the same binding components using an “Object” data source. Just create a data source and select a WCF generated class. Then drag the data source over to a window design surface. This is functionality is available in Visual Studio 2010 for both Windows Forms and WPF apps.
That’s all there is to it. Please let me know if this answers your question.
Cheers,
Tony
Tony:
Excellent. Work Flawlessly!!!!
Thanks,
Pablo.
These posts always remind me of a scene in a movie called Fan Boys where the star wars guys duke it out with the star trek guys.
Rob Conery postsed some good words on the topic: http://blog.wekeroad.com/2009/12/26/thoughts-on-ef-vs-nhibernate-redux
I have been working with nHibernate for a year or so and find it very powerfull. It has a steep learning curve and needs a deep understanding of the inner workings and mappings to really get it to shine. There are some amazing features like futures, result transformers, lucene and more. The learning curve is steep, but manageable. Getting various stacks to play nice can also be challenging for new learners. MS will no doubt cover the docs in detail and will have tons of resources by comparison. Nhibernate has 1 book – its great though.
As an out-of-the-box solution, I feel EF will be easier to work with for most developers and with MS pushing it, will be more appealing for most, especially now with POCO support.
My current framework has been developed to allow either EF or nHibernate to plug in and take over as the orm. Some initial config work, DI and unit of work pattern allow the app to be agnostic as to who is handling mapping and data access. Ritesh Rao has a great project called nCommon which is well worth checking out to appreciated both architectures: http://code.google.com/p/ncommon/
In a nutshell – as a developer you need to know both and the concepts are the same. Once you have a solid understanding, it will come down to personal preference.
PS – Ster Trek sucks
I’d like to take this moment to bring the reality of this comparison to light.
It isn’t about which product has more features, is easier to use, or is more efficient than the other. What you want to look at first is your application design and ask yourself this:
“Are we (am I) writing a domain-centric application, or a data-centric application?”
If you cannot tell, then any differences between the products will be pointless. If you can, then read on.
NHibernate is geared toward the domain-centric application, where you must maintain a proper entity ownership pattern. For example:
// To save a new order you must do so via the custom it belongs to
customer.AddOrder(order);
customerRepository.Update(customer);
If you were to expose the customerId in the Order entity and try doing the following, instead:
orderRepository.Insert(order);
It might actually save to the database (depending on your mappings), but due to the way NH caches data, subsequent selects will not reflect the change.
This is where the MS products shine. They are geared towards the data-centric application, making the second code example a reality.
In the end, your decision should not simply be “which ORM is better” but “which ORM is better for OUR needs?”
Tony, you can search Ayende site in google with
+ef +extensibility site:ayende.com
😉
Pingback: FluentNHibernate vs. Code First in EF 4.1 « <CharlieDigital />
Very good stuff!
NH allows you add a lot of garbage code and garbage files.
you dont have to worry about that in EF cause theres only 1 file …. forever .. amazing
Oh yes, one file. I got a database with 500+ entities. One file to rule them all. It is NOT amazing, the designer sucks in this case, one file sucks too. I HAVE to use Nh, EF is just not an option for such projects. And don’t say it is so uncommon to have large databases.