There’s a fairly common misconception that EF4 was the fourth version of the Entity Framework. It’s a reasonable assumption to make, but actually EF4 was only the second released version of EF. It was called EF4 not because it was version 4, but because it was released as part of .NET 4.0.
You may also have heard the EF4.1 builds on top of EF4 without changing the “core” libraries. What does this mean? Read on to find out more and dazzle your friends with EF trivia.
EF1 in .NET 3.5 Service Pack 1
This was the first version of EF available as a fully-supported RTM release. It shipped as part of Service Pack 1 for .NET Framework 3.5. This version contained core support for the Entity Data Model (EDM) on which both the Entity Framework as an Object-Relational Mapper (ORM) and WCF Data Services/OData are based. However, maybe because of it’s focus on EDM, the ORM part of this version of EF lacked some fairly basic features and was a little bit hard to use.
EF4 in .NET 4.0
After releasing EF1 we knew the next version would ship as part of .NET 4.0, but what should it be called? The assembly versions would all be 4.0 and it would ship as part of a 4.0 product…so it seemed like it would cause confusion to call this EF2. So to be in alignment with .NET 4.0 this became EF4. (Or EFv2 squared, as the t-shirts said.)
EF4 added a lot of enhancements to the core of the framework, such as improved SQL generation. However, perhaps the most notable additions were to the basic ORM features and usability—EF4 added support for POCO entities, better support for mocking with IObjectSet, lazy-loading through dynamically generated proxies, FK associations, and many other improvements. EF4 made the Entity Framework much more useable as an ORM…although some of the APIs could still be a bit hard to use.
While still wrapping up work on EF4 some of the team were looking to the future and working on enhancements such as the Code Only prototype, which eventually became Code First. Others were looking at the usability of the API and wondering if we could unleash some of EF’s power by making it easier to use. All of this came together with the DbContext and Code First experiences. The DbContext API is not just about Code First and Code First is not just about the DbContext API, but they both work together synergistically to provide markedly improved usability for EF. All this work has just been released today as EF 4.1.
The interesting thing about all this work is that it doesn’t include any changes to the EF4 code at all. Not one. EF4.1 is a library that sits on top of EF4 as shipped with .NET 4.0 and uses the EF4 library for all its ORM functionality. EF4.1 is all about the way you build your model and use the API. Because EF4.1 doesn’t change anything that is already shipped as part of the .NET framework we were able to (relatively) easily release it out-of-band, allowing us to get this work to you sooner rather than later.
Of course, the consequence of this approach for EF4.1 is that there were some things we just couldn’t do in this release. The best example of this is enum support. It’s not that the team doesn’t recognize the need for enum support; we do. It’s consistently been at the top of our feature list since EF4 was released (and was a very hard cut to make for EF4). We have had people working on it and have a lot of the code done…but this code includes changes to the core ORM functionality. So there was no way we could put it in the EF4.1 release—enums isn’t just about the way you build your model or use the API.
So, there you have it. Despite what “4.1” might suggest there have only been two full versions of the Entity Framework and one additive assembly.
Thanks for reading!