Entity Framework – a sorry history, new release 5.0 and future openness

During the quiet days of July, Microsoft announced it would be moving to an “open development model” with Entity Framework. Given these news – and the ever-advancing version numbers – it’s a good time to look at the history and future of the Entity Framework. Oh, and version 5 is out.

2008: Microsoft launches the first stab

In 2007 .NET 3.5 was brewing, and with it came LINQ, a formidable language addition for querying disparate data sources. While Microsoft demonstrated the relational query features using LINQ to SQL, a poor man’s simplified ORM tool, everybody knew it wouldn’t work for complex enterprisey applications. The promises of Microsoft’s next generation of relational data access tooling were laid on Entity Framework, a modeling effort so immensely comprehensive that most people couldn’t quite even grasp its scope.

What is EF’s scope, then? It uses an Entity Model (.edmx) to map database constructs to entities. EF enables you to create fairly complex mappings, to the extent that your object model may actually have little similarity to your relational schema. It then enables you to query this model not only with LINQ, but also using Entity SQL, a language that enables you to query the object model, not the data storage (much like HQL in NHibernate). A query language on the entity level adds intuitivity particularly with complex mappings, and enables multi-level navigation expressions such as “Customer.Address.ZipCode” normally achieved through use of joins.

The birth of Entity Framework was met with exceptional controversy. Few infrastructure products have provoked a Vote of no confidence petition signed by almost a thousand developers, including a couple of dozen MVPs. The key criticism was aimed at the clumsiness of writing modern, clean code: the entity classes had to be populated with boilerplate code, lazy loading was a pain to implement and the advertised disconnect between data model and a business-driven entity model was relatively cumbersome to achieve.

An extra insult was added by the launch date: .NET 3.5 and Visual Studio 2008 shipped without Entity Framework, as Microsoft simply missed the deadline. After the November 2007 release, it took an  additional year to push out Entity Framework with .NET 3.5 Service Pack 1. With this delay, many had already clung on to the “simplified EF” LINQ to SQL shipping with .NET 3.5 – or competing ORM products. And to further mess things up, it was then announced that development focus would be on EF. People read this as having the LINQ to SQL project terminated – perhaps a slightly dramatized conclusion, but not entirely baseless.

2009-2012: Critical fixes and agility

Then Entity Framework took a leap. The next version was slated to ship with .NET Framework 4 in spring of 2010. It was named Entity Framework 4, skipping two major version numbers since EF1 a year before. And with features that really addressed many of the key problems the loudest critics had been preaching about: persistence ignorance (entity classes need not be developed with the ORM tooling in mind), lazy loading and model first (i.e. generate database from the model designer), just to name a few.

Entity Framework version history.
Click to enlarge.But the 4.x wave of Entity Framework also meant policy changes. First off, the even though the hop in major version numbers was based on getting abreast with .NET versioning, the team declared they would start using Semantic versioning (from 4.2 onwards) and ship the product using NuGet, enabling updates out-of-sync with the slowish .NET Framework releases.

And then we saw quite some releases. First, there was 4.1, the first one pushed through NuGet. It added code-first features, enabling you to write your entity classes in code and generate the rest from there). That was followed with some bug fix releases and then by EF 4.3. It added support for migrations, which enable you to easily upgrade your database schema as your application gets upgraded.

Finally, Entity Framework 5.0.0 was released to NuGet distribution on 15th August 2012, and boasts support for .NET Framework 4.5 (it is worth noting that EF 5.0 is only available on NuGet, despite the nigh-simultaneous release with .NET 4.5!). Included are performance improvements and support for some still-missing features of SQL Server and the .NET Framework: enumerations, multi-result stored procedures and table-valued functions.

2012+: The open source phase

As of Entity Framework 5.0, the source code is publicly available. More importantly, the Entity Framework team has also taken a more open development model: they have a public issue tracker, publish their checkins as they go – and perhaps most importantly, accept outside contributions. So far, the community activity around the oncoming EF 6 has been mild. Put in Git terms, there have been some 30+ forks and two pull requests (at the time of writing). But that said, there is a lot of promise here, at least on three fronts:

Top EF feature requests
(from UserVoice)

1. Improved SQL Generation
2. Batch updates
3. Query-level caching
4. Multiple databases per model
5. Designer performance

First, Microsoft is shrewd at setting priorities. They will leave bugs unfixed if they don’t concern a large enough user base, and if your critical bug happens to have an impact too small… Well, sorry. Now, in addition to your possible support contracts, you also have the usual open source options: Fix it yourself, or have someone fix it for money. Custom builds are easy, although you do lose the support benefits then. The good part is that if your bug fix passes the quality criteria for contribution, you can get Microsoft to support it from the next version on.

Second, just having the source available enables learning and debugging of issues previously quite opaque.

Third, having the Entity Framework solutions open for perusal is a catalyst for other frameworks, or perhaps forks (custom versions) of EF itself. Although EF isn’t the most innovative runner in this race, it still provides a reasonable baseline for any custom implementations.

One more interesting tidbit: Currently the repository contains code the Entity Framework and its Power Tools. In the future, the source code of the Entity Framework (edmx) designer will also be added. This will be a significant boon to many, as there aren’t too many open source examples of a complex Visual Studio designer.

EF6 to include async and code first improvements

Entity Framework 6 has no announced schedule, but it has a roadmap. The key items currently mentioned include Task-based async, stored procedures and DB functions support in Code-first scenarios as well as a possibility for defining custom conventions for Code First.

Presumably, EF 6 will complete faster if the public decides to chip in and contribute patches. But being realistic, it is highly likely that the EF6 release will be mostly driven by Microsoft employees, and they should be in a hurry: The lack of asynchrony support makes EF stand out as a slow adopter of patterns that were quite fully embraced in .NET 4.5.

Platform-wise, Microsoft seems to have a strong desire to promote Entity Framework. For example, Entity Framework 5.0 is automatically included in new ASP.NET MVC 4.0 projects – a somewhat controversial decision in itself. All this will eventually grant Entity Framework more visibility, perhaps elevating it into a de facto standard ORM role on the .NET platform. But EF is nowhere near complete, so the competition will likely keep going on for at least a few years.

Tags: Entity Framework, open source, ORM, roadmaps