ORM (Object-Relational Mapping) technology has been around a while now, and has moved from niche to mainstream along with code generation, unit testing, and agile development. ORM, in a nutshell, allows a developer to link object models to relational database schemas, eliminating the impedance mismatch inherent between relational databases and object-oriented programming languages. ORM can effectively eliminate the tedium and clumsiness of writing low-value SQL queries and can provide some pretty significant improvements in the deployment process. I don’t want to extoll the virtues of ORM too much here, this article will assume you are familiar with the concepts. Popular tools like Ruby On Rails’ ActiveRecord, and Java’s Hibernate are widely used implementations that can give you more background on the technology as well.

Microsoft has recently released Entity Framework 1.0 (EF) in Visual Studio 2008 SP1, it’s first, albeit very late, entry to the ORM world. I have several years experience with open-source NHibernate, a .NET port of Hibernate and the standard ORM technology for the .NET platform. While not perfect, NHibernate has been an essential workhorse in my toolkit, and one that I have leveraged to great success in both simple and complicated projects. I decided to take a look into EF to see how it compared to NHibernate.

The biggest and most obvious difference is that EF has a very slick UI built right into Visual Studio.NET. This UI allows you to use a wizard-style interface to select database objects and generate the entity model with a few clicks. Changes to friendly names and collections are easily done with a simple click and rename.Foreign Key relationships are automatically translated into object collections with no coding necessary. Under the hood this is all code generation – in fact an incredibly complicated set of C# classes that cannot and must not be modified by hand.

NHibernate, by contrast, relies on the much-maligned XML configuration file for it’s mappings. These files are well-known for being antagonistic to new users, but with some experience, are reasonably easy to get down. Visual mapping tools and codegens do exist (I have used a customized MyGeneration template for years) although they are not nearly as polished as the EF designer in Visual Studio 2008.

Once I had taken a spin through the EF designer and generated some classes, it was time to perform some basic CRUD operations against my database. EF does not provide pre-built CRUD code, instead it relies on Microsoft’s new LINQ-to-Entities syntax to allow a C#-native, SQL-style syntax for querying the entity model. Writing code to get an object by it’s ID via LINQ is very simple, and writing it in C# with full Intellisense support and syntax highlighting is a nice feature.

NHibernate has a query language too, although not native to C#, it is essentially the same as LINQ, a pseudo-SQL language called HQL. For much day-to-day work there is not much of a difference in the query language aspect between these two ORM’s, but LINQ definitely has the advantage here. The recently released LINQ-to-Hibernate provider should close this gap considerably.

Entity Framework does a good job of hiding the database, perhaps too good of a job. While NHibernate just needs a connection string to access a database, EF uses a set of special files to store the model and it’s mappings. Managing these files and their connection strings can be troublesome when accessing the model from separate projects (i.e. a unit test project and a web app). Also, NHibernate exposes the database connection a bit more explicitly, exposing a Session object and offering numerous ways to control the session, as well as some fairly deep features such as lazy loading, caching, and various collection types which are not present in EF.

The main challenge with EF becomes apparent when you attempt to build an object model beyond the basic object-per-table paradigm the EF GUI exposes. If you want to create a rich object model with modern OO techniques of aggregation, composition, generalization and specialization, it will be very hard to do with the EF designer. Dropping out of the designer presents a level of complexity much deeper than NHibernate’s config files.

EF’s preference for table-per-entity design creates a particular issue with legacy databases, especially databases that don’t expose good key structures (Peoplesoft is a particular example), or multiple database sources. This limitation, in my opinion, is the biggest problem with EF.Most modern software consumes multiple data sources – XML files, databases, web services, file system resources. It is usually beneficial to wrap these resources into a business entity model and not expose the underlying storage. Since NHibernate is basically just a mapping, it is less intrusive into your domain objects, and is less dependent on a ‘database-first’ approach to building out the entity model.

Ultimately, it would appear that EF, while a good first step, is probably not going to unseat NHibernate as the ORM of choice in the .NET framework. While it is an acceptable solution for most basic, CRUD heavy situations (and there are lots of them), it is probably not going to be useful to the people that often use ORM – enterprise developers working across varying data sources looking to simplify their data access into a comprehensible model. It will take time, and potentially several versions, for EF to get to where it needs to be. NHibernate has the inertia, and the large pool of experienced users that is very crucial in these types of tools.

However there is no question EF has incredible potential. Questions persist about NHibernate’s future as it has stayed at v2 for many years. Stability is not a bad thing in my opinion, but Microsoft will catch up fast as they have the resources to do so.Also interesting is Microsoft’s apparent PR blunder around Entity Framework. Announcement that EF would be the data access technology of choice going forward created a backlash around the simpler and more mature LINQ-to-SQL, which had already been in the wild for some time and was being used my many developers. Ultimately we will have to wait until 2010 and .NET 4.0 to see if EF is truly going to be the tool that will wean so many developers off of sprocs and ADO.NET code.