Entity Framework 6 vs NHibernate 4

This article is dedicated to discussing the latest releases of the NHibernate and Entity Framework. NHibernate is (was?) a number one ORM Framework for ages. Its feature list is growing and some things such as code-based mappings and automatic migrations have found a place in Entity Framework. Moreover, it is now open-source, so they are now accepting pull requests as well.

Project Activity

Entity Framework (http://www.ohloh.net/p/entityframework) at 2013-12-10:

 

NHibernate (http://www.ohloh.net/p/nhibernate) at 2013-12-10:

Let’s take a look at the above charts. The number of contributors to the NHibernate project declines while the number of Entity Framework contributors increases. There are three times as many commits to the Entity Framework source tree then to the NHibernate. Additionally, the number of commits to the NHibernate sources declined by 56 percent in last 12 months while the number of commits to the Entity Framework increased by 98 percent in the 12 months.

It is evident the NHibernate community has lost steam while Entity Framework’s community is growing and gaining the speed. Perhaps all of the original NHibernate kids have moved on and thus the community is lacking a clear vision for new releases. I guess it also doesn’t hurt that Microsoft sponsors the Entity Framework.

Latest Releases

Now, let’s review the new features that were added to the Entity Framework 6 version and upcoming NHibernate 4 release.

Entity Framework 6 new features

• Async Query and Save
• Connection Resiliency
• Code-Based Configuration
• Dependency Resolution
• Interception/SQL logging
• Custom implementations of Equals or GetHashCode on entity classes
• Custom Code First Conventions
• Code First Mapping to Insert/Update/Delete Stored Procedures
• Configurable Migrations History Table
• Multiple Contexts per Database

NHibernate 4 planed features

• [NH-3164] - Support building NHibernate on .Net 4 (removing dependency on Iesi.Collections)
• [NH-3166] - Support for Microsoft Sql Server 2012
• [NH-3193] - MsSqlCeDialect should correct override string manipulation functions
• [NH-3195] - MsSqlCeDialect should support TOP limit
• [NH-3284] - New Ingres9+ Dialect
• [NH-3349] - Add support for managed ODP.NET

You can see that Entity Framework 6 offers quite a few new and interesting features while the NHibernate 4 release just replaces the third party Iesi.Collections library with the native alternative of .NET Framework (no real exciting things here).

Supported Database Providers

Entity Framework (http://msdn.microsoft.com/en- us/data/jj730568#providers at 2013-12-10):

• Microsoft SQL Server provider
• Microsoft SQL Server Compact Edition provider
• Devart dotConnect Data Providers
• Firebird provider

Note #1: If you’re so inclined, you can find more unofficial providers on StackOverflow.com. For example, I was able to install and use Npgsql.EF6 package form NuGet (though it’s the pre-release version: 2.0.12-pre4) to connect to PostgreSQL database.

Note #2: Any inclusion in this list does not indicate the level of functionality or support for a given provider, only that a build for Entity Framework 6 has been made available (quote from MSDN site).

NHibernate (http://community.jboss.org/wiki/DatabasesSupportedByNHibernate at 2013-12-10)

• Microsoft SQL Server (including Compact Edition)
• Oracle
• Microsoft Access
• Firebird
• PostgreSQL
• DB2 UDB
• MySQL
• SQLite

​I do need to address the fact that most providers are still broken after the Entity Framework 6 release–provider migration is lagging behind. The same could be said about SQL generators for Code-First Migrations. At this point, only Sql Server providers are in sync with Entity Framework releases. On the other hand, all NHibernate providers are in working condition and new releases don’t break them. In my opinion, NHibernate is the clear winner in this area as many users rely on NHibernate to develop applications for more than one provider.

Code First Mapping

Both NHibernate and Entity Framework support the Code First Mapping feature. In Entity Framework it was introduced in version 4. However, at that time it received a lot off criticism due to a broken model (http://ayende.com/blog/4246/what-is-up-with-the-entity-framework-vnext, http://ayende.com/blog/4038/why-defer- loading-in-entity-framework-isnt-going-to-work). However, after the version 6 release, it appears that Entity Framework and NHibernate are on equal footing in this particularly area.

Migrations

Entity Framework

• Built-in schema migration support since version 6
• Also supports seeding of the initial database

NHibernate

• Supports only initial schema generation
• Third party open source tool exists (FluentMigrator could be usedhttps://github.com/schambers/fluentmigrator)

For me, built-in support for migrations is a must-have feature for any modern ORM. That’s why Entity Framework is the clear winner despite the fact that a number of supported SQL generators in Entity Framework migrations are very limited for version 6 at the time of this post.

Support of Asynchronous Operations

Entity Framework

• Built-in support since version 6

NHibernate

• None (and no clear answer if those will be implemented in the future releases)

As I understand, in order to add asynchronous operations API to NHibernate it would require a major refactoring of code and architecture. So I don’t think that this will be added to NHibernate any time soon. Because of this, Entity Framework comes out on top in this category. However, it remains to be seen how useful programmers will find this feature.

Connection resiliency

Entity Framework

• This feature was added to version 6; the connection resiliency feature automates the process of retrying failed SQL statements

NHibernate

• Third party solutions exist with NHibernate.SqlAzure (https://github.com/MRCollective/NHibernate.SqlAzure based on Microsoft Transient Fault Handling library)

Code-Based Configuration

Entity Framework

• ​Available from version 4.1; Entity Framework automatically finds a class that derives from DbConfiguration; you can use the DbConfiguration class to complete configuration tasks in the source code that you would otherwise do in the web.config file (http://msdn.microsoft.com/en-us/data/jj680699)

NHibernate

• Loquacious Configuration API was included in NHibernate Core during version 3.2 (but not widely used)
• Third party project FluentNHibernate (http://www.fluentnhibernate.org/ in development since 2008 year and widely used)

Again, it is one of those NHibernate contradictions - Loquacious Configuration API is included in the core but the third-party FluentNHibernate library is more widely used. I don’t understand why NHibernate developers have not fixed this and included the FluentNHibernate into the core since FluentNHibernate existed before Loquacious Configuration API was introduced. Instead they chose to write new API. I think in this area both frameworks are fairly equal, though NHibernate loses some points because it is unclear that API should be used.

Querying API

Entity Framework

• LINQ to Entities–the most commonly used
• Entity-SQL–object-oriented, database-independent querying language
• Plain SQL

​NHibernate

• LINQ provider for NHibernate and Query Over–Similar to Criteria API , but uses strongly-typed LINQ expressions instead of strings. This is also the most commonly used today.
• Criteria API–This is an implementation of the Query Object pattern where you create a semi-abstract conceptual representation of the query you wish to execute by means of a class model)
• HQL–a database-agnostic, object-oriented, SQL-alike language that exists since NHibernate’s creation)
• Plain SQL
  (http://weblogs.asp.net/ricardoperes/archive/2012/06/07/differences-between-nhibernate-and-entity-framework.aspx)

Per usual with NHibernate, its flexibility is its strongest and weakest point. Since it supports so many querying API’s  not all of those are equally matured. For a novice user, it can be unclear which query API to use. For example, when the LINQ provider was introduced it was very unstable and many methods were not implemented at all. At the same time, Query Over API was introduced. So, what is the advantage? There is always more than one way to do querying and if you don’t like using one API you can always use another (or mix them)–We like choices.  Contrarily, I think a novice user may like that in Entity Framework all decisions are already made by the framework developers. Overall, NHibernate is a bit more flexible and offers QueryOver API (almost SQL like feel). Additionally, NHibernate has a unique ability to merge several separate queries into one batch by its Futures feature.  Despite NHibernate offering a few more features than Entity Framework, I don’t think we can say one is a clear winner.

Both Frameworks in Action

Illustrated below is a simple database schema we will perform queries against:

We will query a root entity with the child collections.

Entity Framework Linq API

using (var db = new SchoolContext())
{
  var students = db.Students
     .Include(s => s.Enrollments)
     .Include(s => s.Enrollments.Select(e => e.Course))
     .Where(s => s.LastName != null )
     .OrderBy(x => x.FirstName)
     .ThenByDescending(x => x.LastName)
     .Skip(1)
     .Take(3)
     .ToList();
}

Nhibernate Linq API

using (var session = sessionFactory.OpenSession())
{
  var students = session.Query<student>()
     .FetchMany(s => s.Enrollments)
     .ThenFetch(e => e.Course)
     .Where(s => s.LastName != null )
     .OrderBy(x => x.FirstName)
     .ThenByDescending(x => x.LastName)
     .Skip(1)
     .Take(3)
     .ToList();
}
</student>

NHibernate QueryOver API

Student studentAlias = null ;
Enrollment enrollmentAlias = null ;
Course courseAlias = null ;

using (var session = sessionFactory.OpenSession())
{
  var = session.QueryOver(() => studentAlias)
     .Left.JoinAlias(() => studentAlias.Enrollments, () => enrollmentAlias)
     .Left.JoinAlias(() => enrollmentAlias.Course, () => courseAlias)
     .Where(() => studentAlias.LastName != null )
     .OrderBy(() => studentAlias.FirstName).Asc
     .OrderBy(() => studentAlias.LastName).Desc
     .TransformUsing(Transformers.DistinctRootEntity)
     .Skip(1)
     .Take(3)
     .List<student>();
}
</student>

Interception/SQL Logging

Entity Framework

• Introduced in the Entity Framework 6
• Added ability to log generated SQL statements without using a wrapping provider
• The interception code is built around the concept of interception interfaces; interfaces inherit from IDbInterceptor and define methods that are called when the framework performs some action; one interface per type of object being intercepted; registration of interceptor is done through DbConfiguration class
• In the current version public interception interfaces exist for DbCommand execution and DbCommandTree creation

NHibernate

• The IInterceptor interface provides callbacks from the session–it allows the application to inspect and/or manipulate properties of a persistent object before it is saved, updated, deleted or loaded; one possible use for this is to track auditing information; you may either implement IInterceptor directly or extend EmptyInterceptor (recommended way)
• It is possible to use the NHibernate2 event architecture; the event system can be used in addition to or as a replacement for interceptors​

The goal for the interception feature is to allow external code to observe and potentially intercept framework operations.The very clear winner in this area is NHibernate, since its interception/event capabilities are richer (currently Entity Framework only supports interception of DbCommand execution and DbCommandTree creation)

Documentation

NHibernate falls badly behind with regard to documentation because its process is outdated and resources for learning are scattered all over the Internet. Not only is it difficult for the user to locate information on how to use the framework but it is difficult to know what to search for (for example what query API is recommended). Conversely, Entity Framework has centralized place for learning about it with up-to date tutorials included.

Final Thoughts

A few years ago if someone would have asked me what ORM framework I would recommend for a .NET project I would have said NHibernate. However in today’s tech landscape, NHibernate falls behind Entity Framework. I don’t necessarily believe its worth switching from NHibernate to Entity Framework if you have experience with the former. However, if you are a novice developer, Entity Framework may be easiest to learn. Ultimately, the choice is yours.

 

from:http://www.devbridge.com/articles/entity-framework-6-vs-nhibernate-4