The next version of Entity Framework will be called “Version 7” and will be released as part of the next version of ASP.NET, called “ASP.NET 5.” If you’re currently on EF6, you might jump to the conclusion that you should upgrade to EF7 as soon as it hits the streets. But the EF team has made clear that you’re going to want to hold off upgrading to EF7 for a while:
“We won’t be pushing EF7 as the ‘go-to release’ for all platforms at the time of the initial release to support ASP.NET 5. EF7 will be the default data stack for ASP.NET 5 applications, but we will not recommend it as an alternative to EF6 in other applications until we have more functionality implemented.”
This means that the initial release of EF7 won’t include all the features a real-world ORM (Object-Relational Mapping) tool should support (for example, inheritance mapping). But if you can live without those features, or if you are developing an ASP.NET 5 app that needs to target CoreCLR, then feel free to make the move to EF7.
So when might you want to upgrade from EF6 to EF7?
For some folks the answer will be, “Maybe never.” That’s right. There are certain features and development approaches that are being deprecated. The most notable is support for EDMX-based development, which is sometimes referred to as “model first” or “designer based.” Going forward, EF7 and beyond will only support code-based modeling, also known as “code first,” but which also includes reverse engineering code first entities from an existing database.
So if you have heavy investment in EDMX-based models, then you might want to completely rule out upgrading beyond EF6. After all, EF6 is mature, feature-rich, stable and performant. Because of that, it’s not going away anytime soon, and the team is continuing to fix defects and add minor features. It also might take a while for providers other than SQL Server, such as Oracle, to release versions that are compatible with EF7.
So what kinds of applications would be good candidates for using EF7?
- ASP.NET 5: This will be a “cloud-friendly” version of ASP.NET that allows you to target a stripped down and NuGet deployable version of the CLR, called .NET CLR Core. EF7 was re-written from the ground up mainly to support this scenario. Besides, EF6 won’t support CoreCLR and you’ll have to use EF7 if you want to take advantage of the version of .NET that targets the cloud.
- Apps that use EF with code-based modeling (aka Code First), where you don’t use features not yet supported by EF7 and you’re willing to be patient (or volunteer to help out). The bonus here is that EF7 is deployed as a set of Portable Class Libraries that can run on .NET 4.5.1, Windows 8.1 and Windows Phone 8.1 (and by extension on iOS and Android via Xamarin). There is also an In-Memory provider that is useful for testing scenarios.
- You want to target non-relational data stores, such as Azure Table Storage or Redis, and you’re willing to wait for those providers to be written. In order to focus on rounding out the basic feature set and supporting ASP.NET 5, the EF team froze their work on non-relational providers. They will eventually come along, but you may need to wait a little while.
- You want to target a local SQLite database on a mobile device and you’re willing to wait some more. Just like non-relational stores, development on the SQLite provider is being postponed until after the initial release and inclusion of basic features.
Beyond the support for ASP.NET 5, non-relational stores, and mobile platforms, most of what’s cool about EF7 is under the covers. It’s being written in the same modular fashion that makes ASP.NET 5 a compelling story. The idea behind it is to cut loose from the bonds of its legacy to provide a product where you can pick and choose just the components you need and can more easily insert custom extensions and configurations into the pipeline. This is what makes it cloud-friendly, because it reduces the application footprint in an environment where memory and processing resources are pay-as-you-go. And just like ASP.NET 5, EF7 has been designed so that dependency injection and testability are first-class citizens.
Starting from scratch has enabled the EF team to add features which were difficult to plug in while tethered to the old code base. These include batch updates (sending multiple statements to the database in a single round trip) and the ability to define unique constraints on entities besides the primary key. EF7 will also allow parts of queries to be executed locally and for providers to handle queries which produce multiple result sets.
As stated on the Entity Framework Wiki on GitHub, “EF7 is a lightweight and extensible version of Entity Framework that enables new platforms and new data stores.” It represents a fresh and exciting evolution of Microsoft’s flagship data access platform. And while the most dramatic features are yet to come, deploying EF as NuGet packages allows the team to rev the product in much more rapid cycles. And being hosted on GitHub provides for the kind of community feedback and involvement that was more difficult to achieve prior to the cultural shift toward openness we’ve seen as the company has embraced the open-source movement. It may seem like a bumpy ride at times, but if you’re adventurous, don’t hesitate to climb on board and have fun. If, however, you’re heavily invested in EF6, there’s no reason to jump ship before both you and EF are ready.