Deciding between NHibernate vs Entity Framework? [closed]

Answer 1

I've had very limited experience with EF (a few blog posts and tutorials), but plenty of experience with NHibernate.

Microsoft is consistantly behind where the OpenSource movement is, and this is definitely the case with NHibernate. When EF 1.0 was first released, it lacked support for key features such as POCO support and persistence ignorance, it required your entity classes to extend a base entity class from EF, so your entity classes weren't completely decoupled from EF. This effected maintainability and unit testability, as well as the ability to switch ORM providers if need be.

NHibernate on the other hand allowed you to completely decouple your entities from NHibernate itself. EF 4.0 has caught up somewhat in this regard, it's Code First Development approach (recently announce by Scott Guthrie) is a step in the right direction.

NHibernate itself has some very powerful mapping capabilities such as Inheritance mapping, mapping of component classes (think Address object on a Customer entity), unidirectional entity association mapping. It lets you take full advantage of the power of Object Oriented programming (Encapsulation, Polymorphism, Inheritance etc.) inside your domain model, think of your entity classes as encapsulating behavior and not just data containers. If you're aspiring to build your domain model to the principles of Domain Driven Design, then NHibernate is a very good fit for this. I can't speak directly on EF 4.0 on these points, only from what I hear from other NHibernate users trying to use EF 4.0, but EF 4.0 still lags behind in these areas, but it's gaining ground.

Answer 2

As someone who has worked with and continues to support codebases using both NHibernate and Entity Framework I came across this old question and somewhat out-of-date answers and thought I'd post a summary update. Summary because you could write a book comparing the two in detail.

As of late 2019, both of these tools are good and either of them will do an excellent job for most people who want to use an ORM.

In 2017 I moved my team/standard use for new code from NHibernate to Entity Framework.

Why did we start with NHibernate? Back then (2013), EF was fairly new and missing features, and I felt Microsoft needed to prove they were committed to the technology. Both of those concerns have now been addressed. NHibernate over the years has disappointed with support for LINQ and Fluent configuration (we still use XML mappings). Both of those problems have now also been addressed.

So why move to Entity Framework? I decided it was time to move to entity framework because we were moving to .NET Core and it had got to the point where it was mature and being treated as a core part of .NET. As such it is updated with new features as they come out in .NET; ready with .NET core (missing some features to start with, but good now), good LINQ support, Fluent configuration the default, well integrated with ASP.NET Core, integrated with the new logging and DI frameworks, all the features we needed. I still think it was the right choice.

What to choose? My advice would be: if you are a Java developer familiar with Hibernate or porting Java code which uses Hibernate, there is little reason to move to EF, and you could move later if you need to. If you are .NET through and through, I think EF is the sensible choice, though there may be edge cases where NHibernate is better.

A common use of ORMs is to isolate from the underlying database: SQL Server, MySQL, Oracle etc: these days EF claim to support more RDBMS than NHibernate, so another tick for EF.

Being an older product with a long history (coming out of the Java ecosystem), NHibernate does have options and features which are not available in EF: HQL (Hibernate Query language, a custom query language), support for a wider range of ORM approaches, a wide range of configuration and other options, tools available. However, I haven't missed those and |I like the trimmed down feel of the latest versions of EF; it does what I need with no legacy.

Answer 3

I'd say the fact that Entity Framework is from Microsoft is both an advantage and a disadvantage. You're getting a framework right from the same source as .NET itself. The bad news is that Microsoft often obsoletes its own code base without regard for backwards compatibility.

NHibernate does not come from Microsoft, and there's no standard other than what the developers of Hibernate and NHibernate say belong in their code. The good news is that they've generally paid attention to backwards compatibility. There's a large user base, because Hibernate has been around for a while.

One of the features I like best about Spring is that they don't take decisions like this away from you. Spring has its own JDBC features, but it supports Hibernate, TopLink, JDO, iBatis, and JPA. You're also free to inject your own classes if you decide to go another way (e.g., NoSQL). Why should your choices be dictated by the framework choice? It's very nanny-ish: "We're Microsoft; we know what's best for you better than you do."