Developer Ricardo Peres of Portugal has published a seemingly unbiased comparison of the leading .NET ORMs: NHibernate and Entity Framework. While we recommend anyone considering both to read his article, Differences Between NHibernate and Entity Framework, we are going to tough on some of the key differences.
Architecturally, NHibernate is based on Java’s Hibernate ORM. Ricardo writes,
In NHibernate, there is a separation between the Unit of Work and the configuration and model instances. You start off by creating a Configuration object, where you specify all global NHibernate settings such as the database and dialect to use, the batch sizes, the mappings, etc, then you build an ISessionFactory from it. The ISessionFactory holds model and metadata that is tied to a particular database and to the settings that came from the Configuration object, and, there will typically be only one instance of each in a process. Finally, you create instances of ISession from the ISessionFactory, which is the NHibernate representation of the Unit of Work and Identity Map. This is a lightweight object, it basically opens and closes a database connection as required and keeps track of the entities associated with it. ISession objects are cheap to create and dispose, because all of the model complexity is stored in the ISessionFactory and Configuration objects.
Commenter Morten Mertner adds, “NH just never was able to win me over. It has an impressive feature list, but it's not an easy to use product and the API/design smells of its Java inheritance (in the same way that many Java API's are too enterpricey and over-architected; YMMW).”
Entity Framework follows a more traditional .NET design where everything is encapsulated in a single ObjectContext or DbContext. This makes using the object far more straight forward, but the downside is that the “class is therefore not lightweight as its NHibernate counterpart and it is not uncommon to see examples where an instance is cached on a field.”
In regards to mapping, a key difference between NHibernate and Entity Framework is that the former supports XML-based mapping files that are deployed separately. In theory this allows you to use the same object model against different database schemas without recompiling the application. In practice this is rarely used.
There are several areas where the older NHibernate is ahead of Entity Framework. Ricardo offers more detail, but briefly they are:
- Associations: Both support 1 to 1, 1 to many, and many to many, but NHibernate also supports various order, unordered, and indexed options. It even has an immutable, indexed list.
- Caching: NHibernate offers a second-level cache with numerous implementations. Entity Framework doesn’t have any built-in support for this, but there are samples for adding second-level caching.
- ID Generation: NHibernate offers roughly a dozen strategies depending on how you count them. Entity Framework only offers the main three for SQL Server: identity columns, GUIDs, and manually assigned.
- Events: Entity Framework only has two event-based extension points: ObjectMaterialized and SavingChanges. “NHibernate has a very rich event model, that exposes more than 20 events, either for synchronous pre-execution or asynchronous post-execution”.
- Cascading: “Both support cascading for collections and associations: when an entity is deleted, their conceptual children are also deleted. NHibernate also offers the possibility to set the foreign key column on children to NULL instead of removing them.”
- Flushing Changes: NHibernate offers an automatic mode where changes are saved when necessary, such as “if there are dirty instances of an entity type, and a query is performed against this entity type”. FlushMode.Auto is actually the default, but it is not unusual to see auto-flushing being blamed for performance problems.
There a few areas where Entity Framework currently shines over NHibernate such as:
- Tracking Changes: While both default to change tracking at the unit of work level, Entity Framework also offers self-tracking entities.
- Integration: Entity Framework of course has close ties with Visual Studio and various ASP.NET and WCF libraries.
- Documentation: “This is another point where Entity Framework is superior: NHibernate lacks, for starters, an up to date API reference synchronized with its current version.”
- Queries: Craig writes, “NHibernate is much more feature rich except for one area, Linq support. Because Linq or other query language is the most visible part of the ORM for many users it gives a false impression of capability.”
There are some areas where both could use some improvement such as batching. And neither ORM comes close to SQL Alchemy when it comes to truly leveraging SQL’s advanced features such as common table expressions.
It should be noted that both projects are quite active and improvements to both are seen on a fairly regular basis. So if both meet your minimum requirements, then consider focusing more on the design patterns and philosophy of the libraries than the feature list.