Stack OverflowEntity Framework 4 vs NHibernate
[+112] [10] Deependra Solanky
[2009-10-28 18:07:22]
[ .net nhibernate entity-framework orm ]

A lot has been talked about Entity Framework first version on the web (also on stackoverflow) and it is clear that it was not a good choice when we already have better alternative like NHibernate. But I can't find a good comparison of Entity Framework 4 and NHibernate. We can say that today NHibernate is the leader among all .NET ORMs, but can we expect Entity Framework 4 to displace NHibernate from this position. I think if Microsoft has really injected very good features in EF4 it can give good competition to NHibernate as it has Visual Studio integration, easier to work with and preference is always given to MS products in most shops.

(32) I'd like an update of this comparison. Has much happened since '09? - Phil
[+66] [2009-10-28 23:32:07] John Rayner [ACCEPTED]

EF4 has an out-the-box answer with regard to n-tier development, in "self-tracking entities". Nobody has released comparable code for NHib.

NHib has many features that have not been mentioned as being part of EF4. These include the second-level cache integration. It also has greater flexibility in inheritance mapping, better integration with stored procs / database functions / custom SQL / triggers, support for formula properties and so on. IMO it's basically just more mature as an ORM.

(13) +1 You're right. NH is just mature. EF will catch up by the end of the year. Version 4.0 has already made a dramatic entrance. Give it some time and it'll be bullet-proof by mid 2011. - Sergey
(15) -1 For "EF4 has an out-the-box answer with regard to n-tier development, in "self-tracking entities". Nobody has released comparable code for NHib." There is ISession.Merge in NHibernate which is a lot better then Self-Tracking entities for N-Tier developement for many reasons. - Alex Burtsev
(12) @Alex - In what way is NHibernate an "out of the box" solution? Just to clarify; "Out of the box" means that it works with a vanilla install of Visual Studio. That's an unjustified -1 right there. - Doctor Jones
(9) @DoctaJonez - The way I read it, Alex was contesting the idea that NH has nothing comparable to self-tracking entities, not the part about it being "out of the box". - Jerph
(2) Actually, I have discovered that EF4 has more flexible inheritance mapping. For instance, you can use 2 tables (TPT) as base class + level 1 class and add discriminator to level 1 table, allowing spliting to level 2 classes. In NH, discriminator can only be defined on base class. - Danny Varod
@Danny - in NH you don't define a discriminator property on a class, it's only required in the mapping. - Phill
@Phill - I meant in the mapping of the class to tables. - Danny Varod
[+37] [2011-01-18 06:39:30] Alex Burtsev

Update: I haven't used Entity Framework since version 4.0, so my answer can be outdated. I'm still using NH or pure ADO .NET in my projects. And I don't even want to look at what's new in EF since 4.0, because NH works perfectly.

Actually is pretty easy to compare them when you have used both. There are some serious limitations with EF4, I can name some which I encountered by my self:

EF4 problems:

  • Eager Loading and shaping the result: EF4 eager loading system (Include("Path")) generates improper SQL, with looping JOIN's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it's effectively unusable).
  • Materializer can't materialize associated entities: If you can think you can overcome previous problem by providing you own SQL query, you are wrong. EF4 can't materialize(map) associated entities from JOIN SQL query, it can only load data from one table (So if you have Order.Product, SELECT * FROM order LEFT JOIN Product will initialize only Order object, Product will remain null, thought all necessary data is fetched in query to init it ). This can be overcome by using EFExtensions community add-on, but the code you will have to write for this is really ugly (I tried).
  • Self-Tracking Entities: Many say that Self-tracking entities are cool for N-tier development including the top answer in this thread. Thought I haven't even give them a try, I can say they are not.Every input can be forged, you can't simply take the changes that user sends you and apply them to data base, why not give the user direct data base access then? Any way you will have to load the data user is about to change from DB, check that it exist|not exists do permissions checks etc etc. You can't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it's state and other things, so this information is useless, as do Self-Tracking entities unless you do a private trusted n-tier system for internal use, in which case maybe you could give just plain DB access. (Thats my thoughts about ST Entities and N-tire, I'm not very expericned in N-Tier, so it can change, if I misunderstood something here comment it)

  • Logging, Events, integrating business logic: EF4 is like black box, it do something and you have no idea what it do. There is only one event OnSavingChanges where you can put some business logic you need to run before something happens with DB, and if you need to apply some changes to business objects before something happens you will have to dig in ObjectStateManager, and this is really ugly, code can become huge. If you for example using Repository pattern and what to be notified on changes made to DB in clean object way, you will have hard time doing this with EF.

  • Extensibility: All EF code is private and internal, if you don't like something (and you will not like a LOT if you are serious about EF using), no way you will change this in easy way, In fact I'm sure it's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it's based on extensions methods, and different "hacks" to make EF little more usable, and the code is pretty ugly (and it's not authors fault, when everything in EF is private this is the only way to extend it).

I can continue to write bad things about EF and how painful it was for me to work with it for like 20 pages, and maybe I will.

What about NHibernate? It's absolutely different level, it's like comparing PHP to C#, EF4 is like in Stone-age, it's like EF is 10 years behind then NHibernate in development progress, and in fact it is, Hibernate was started in 2001. If you have free time to learn and switch on Nhibernate, do it.

(1) EF has been released under the Apache 2 license, that should help with extensibility. - CMircea
(1) @MirceaChirea Thats, great news, I didn't expect this, browsing EF source code right now, pretty interesting reading. - Alex Burtsev
(2) -1 for making several statements preceded by "I haven't used this, but I'm talking anyway." - Kyeotic
@Tyrsius My answer was written, almost 3 years ago, I haven't been using EF for a long time, some things could improve, you can edit my answer to update to to current EF status. - Alex Burtsev
(2) You admit you've never used self tracking entities, but yet you dismiss them. How about only speak to what you know and leave out the ignorant guessing, especially since that entire paragraph is pretty much wrong. - Tom Halladay
[+25] [2009-10-28 20:37:34] zowens

Here's the thing. NHibernate and Entity Framework are really for two different audiences, in my mind. NHibernate would be my choice in building a system with complex mappings, formulas, and constraints (basically anything enterprise). If I wanted to hit-the-ground running with simple data access, I would use Entity Framework or LINQ-to-SQL. NHibernate doesn't have a clear "drag-and-drop" experience quite like EF. Both have their strengths and drawbacks. Comparing them apples-to-apples, frankly, gets you nowhere.

(13) Have you tried ActiveWriter? Entity Framework is absolutely targeted at the enterprise space. I disagree with most of what you said. - Michael Maddox
(1) Disagree all you want but the fact that NHibernate has been around longer is something enterprises DO NOT overlook. - zowens
(1) What is ActiveWriter, I have never heard about this? - Deependra Solanky
(21) -1 This is not a good comparison of NHibernate vs. Entity Framework. Comparing the two by lumping EF in with LINQ to SQL just b/c it has drag-and-drop is disingenuous at best. As far as complexity, what exactly is it that NHibernate can do that EF 4 can't? - Kevin Babcock
(14) Second Level Caching, their queries are HIGHLY optimized, NH forces you to use the UnitOfWork pattern, plus mappings aren't jammed into one file. My opinion (from experience) is that NHibernate is more performant. Disagree with me on that, but I did say that was my opinion. My point in my answer is STILL valid, they BOTH have their strengths and weaknesses. No one can deny that. - zowens
(1) -1 Your answer is mostly a blanket statement saying NH is better. More detail is needed. - halfbit
(2) @MakerOfThings7 that's pathetic... this whole question is subjective. Wake up... - zowens
It's 2013, and NHibernate is still faster than EF, and I'm subjected to using EF every day at work :( - Phill
[+23] [2009-10-30 17:27:25] Joel Mueller

If you think you might ever want to run your code on Mono, NHibernate is probably a better choice no matter what the feature checklists say...

Edit, 8/13/2012:

Entity Framework has been open-sourced, and is now included in Mono as of 2.11.3. This answer is now outdated and should not be relied upon.

Indeed, from it reads "EntityFrameworks - Not available.", and looks like no one is interested in implementing it. So at least for a few years, it's NHibernate or nothing. - user276648
[+12] [2011-05-27 05:17:29] Dean

My take on this is that EF4.0 has came a long way since 1.0 and is catching up to Nhibernate in functionality, but it's not all there yet.

However it is Microsoft, out of the box, and do 100% of what 95% of applications need it to do. However, NHibernate has been doing the same thing for years. Come version 5.0 or 6.0 may catch up, or even surpass NHibernate.

Here is my advice -- if you have time to learn both, then do it. There are several reasons to choose one over the other. If you are writing code for a corporation, it is realistic to expect to be able employees who would be familiar with EF, as it's in all the books and what kids learn in college. If EF will meet your requirements (think about this one long and hard before just saying yes), then it's a perfectly fine solution for now, and in a few years it may (ok, most likely will) surpass NHibernate.

NHibernate is a very mature product with a few years on EF and will most likely do everything you would ever want to do and then some. It has been the best ORM for a while now and a lot of people use it.

[+10] [2009-10-28 18:40:07] YeahStu

I think the fact that EF 4 will have the ability to use POCO and deferred lazy loading will be very big. I could definitely see it gaining traction with the new release.

(7) Don't forget LINQ support. NHibernate still ain't good at it. - Arnis Lapsa
(1) @Arnis, can you provide any links to back that opinion up? - Michael Maddox
(2) @Michael this is apparent when you look through Ayande's blog posts on the subject. LINQ to NH is based on the criteria API at present. The criteria API doesn't allow some of the more complex query functions that HQL can. The next release of LINQ to NH will use HQL instead of criteria API. - zowens
[+5] [2014-05-05 08:21:36] Tomas Kubes

There is an obvious trend [1] of increasing EF popularity over NHibernate, see the picture.

NHibernate vs Entity Framework


What is the point of your answer? - Răzvan Flavius Panda
That according to the trend, people are starting to use googling EntityFramework more over time. And they may have good reason for it. Maybe started to be better. - Tomas Kubes
That could be the case, it could also be the case that it is what is being sugested by default to be used by MS. Also the tooling for EF is quite good. - Răzvan Flavius Panda
[+4] [2009-10-30 14:31:26] Aleksei Anufriev

My 2 cents: we use ef on our desktop client for some cahing etc - no hi loads. An NHib on server side - utilizing Stateless sessions, hilo id generation and batches. Is is quite fast in inserting 3k+messages in db per second. Also it is very flexible and supports lots of dbs, wich is crucial for our product.

[+3] [2012-04-03 13:26:51] Andrew

Mapping directly to stored procedures with a combination of Linq for a logical layer seems the easiest approach. No xml. Generate sql only for interesting queries that are less frequently used or not suitable for stored procedures.

Objects load and store through standard SPs. This approach allows the use of two sql logins. One for the class access through SPs (execute-only permissions) and one for a logical linq module that allows direct table access.

[+1] [2014-07-02 17:29:34] Moisés Gonçalves

Choosing between ORM's by popularity isn't the best thing to do. I've tried to move to EF the past 2years and all I can say is, why the hell I still try to?

ATM my point of view about EF is: "It's made for really small pretty tiny bit systems with no more than 3 tables with less than 1 relationship (0 is better)".

And why do I think like that? 1. Try to update a disconnected graph and see your model scratch;

  1. Try to make TPH with deep inherited trees and you'll find you that you are schackled to a single hierarchy or the system will break.

  2. Try to make more cumbersome queries and watch the whole system eat out the stack :D... overflows happen very often.

  3. Map XML datatypes is based on extensions or the most "hated" NotMapped properties... and it's even worse.

  4. Try mixing SQL query into Linq for more finner queries and you'll break the wall lol.

  5. And the last and most important thing, EF doesn't support property formula ('an awesome resources NH has for legacy databases'), and doesn't support complex type mappings for same table and related tables.

That's my 10cc.