NHibernate vs. Entity Framework 4

.net entity-framework nhibernate orm


Entity Framework's first release has been discussed extensively online (including on stackoverflow), and it is obvious that choosing it when better options exist, such as NHibernate, was a mistake. The comparison between Entity Framework 4 and NHibernate, however, is lacking. We may argue that NHibernate now holds the top spot among all.NET ORMs, but can we anticipate that Entity Framework 4 will overtake NHibernate and take its place? I believe that EF4 may effectively compete with NHibernate if Microsoft injects certain high-quality features into it since it integrates with Visual Studio, is simpler to use, and is often chosen over competing solutions in most stores.

10/28/2009 6:07:22 PM

Accepted Answer

With regards to n-tier development, EF4 includes an out-of-the-box solution in the form of "self-tracking entities." For NHib, no equivalent code has been published.

There are several characteristics in NHib that have not been identified as being included in EF4. The incorporation of the second-level cache is one of them. Additionally, it features improved interaction with stored procedures, database functions, custom SQL, triggers, support for formula attributes, and broader inheritance mapping flexibility. In my opinion, it's only an ORM that is better developed.

10/28/2009 11:32:07 PM

Popular Answer

Update: My response could be out of date since I last used Entity Framework in version 4.0. In my applications, I still use NH or plain ADO.NET. Additionally, NH works flawlessly, so I don't even want to look at what EF has added since version 4.0.

After using both, comparing them is really rather simple. There are several significant restrictions with EF4, and I can list a few that I personally experienced:

EF4 issues:

  • eagerly loading the outcome and moulding it: EF4 eager loading mechanism (Include("Path")) creates incorrect SQL, with looping JOIN's, which would run thousands of times slower than hand-written SQL for many-to-many relationships (it's almost useless).
  • The materializer is unable to materialize related entities.: You are mistaken if you believe that by using your own SQL query, you can solve the prior issue. As a result, if you have Order.Product, SELECT * FROM order LEFT JOIN Product will populate just Order object, Product will stay null, even if the essential data is collected in query to initialize it. EF4 can only load data from one database. EFExtensions community add-on can be used to get around this, however the resulting code is rather ugly (I tried).
  • Self-Reporting Entities: Many people, including the best response in this thread, believe that self-tracking entities are nice for N-tier development. I can claim they are not even though I haven't tried them yet. Every input can be manipulated, therefore instead of just applying the user's modifications to the database, why not offer them direct access to the database instead? In any case, you will need to load the data the user is going to alter from the database, verify that it exists or does not, check for rights, etc. This information is worthless, as are Self-Tracking entities, unless you create a private trusted n-tier system for internal use, in which case you may be able to provide just plain DB access. Otherwise, you will have to load the entity from the database and ascertain its status and other details. (Those are my opinions on ST Entities and N-Tier; as I'm not particularly experienced in N-Tier, they may change. If I've misinterpreted something, please let me know.)

  • Events, logging, and incorporating business logic: EF4 operates like a mysterious black box; you have no clue what it does. There is only one event, OnSavingChanges, where you can add business logic that must execute before something with the database occurs. If you need to apply changes to business objects before something with the database occurs, you must delve into ObjectStateManager, which is really ugly and can result in extremely large code. You will have difficulty utilizing EF to do this if, for instance, you are using the Repository design and want to get notifications of database changes in a clean object manner.

  • Extensibility: Since all of the EF code is secret and internal, there is no way to alter it easily if you don't like it. In fact, I'm sure it would be simpler to create your own ORM from start (like I did), then modify EF to meet your needs. Take a look at the EFExtensions source code as an example; it is built on extensions methods and other "hacks" to make EF a bit more useable, and the code is rather ugly (though this is not the author's fault as this is the only way to expand it since everything in EF is private).

I could go on for another 20 pages complaining about how difficult EF was for me to use, and maybe I will.

NHibernate, what about it? Comparing EF4 to C# is like comparing PHP to the Stone Age; EF is 10 years behind NHibernate in terms of development growth, which is really the case since Hibernate was founded in 2001. If you have some spare time, learn how to activate Nhibernate.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow