The official source of information on Managed Providers, DataSet & Entity Framework from Microsoft
At TechEd North America we were excited to announce our plans for EF7, and even demo some very early features. This post will cover the announcements we made during the session. You can also watch the recorded session from TechEd (the EF7 content starts at 46:40). When watching the demos please bear in mind that this is a very early preview - not all the features shown are even submitted into the main code base yet.
Entity Framework Session @ TechEd North America 2014
Entity Framework is a popular data access choice for traditional client and server applications that target the full .NET Framework. This includes applications built with technologies such as WPF, WinForms and ASP.NET. As we look to the future, we believe there is value in providing the same programming model for data access on the remaining platforms where .NET development is common. This includes Windows Store, Windows Phone and the Cloud Optimized .NET that was announced at TechEd. EF7 will work on all of these platforms as well as Mono, on both Mac and Linux.
For Windows Phone and Windows store, the initial goal is to provide local data access using EF. SQLite is the most common database of choice on devices, and will be our primary story for local data with EF7. The full provider model will be available though, so other data stores can be supported also.
In the TechEd session you can see a demo of EF7 being used in a Universal App (targeting Windows and Windows Phone) starting at 1:04:00.
While parts of Entity Framework are clearly tied to relational data stores, much of the functionality that EF provides is applicable to many non-relational data stores too. Examples of such functionality include change tracking, LINQ, and unit of work. In EF7 we will be enabling providers that target non-relational data stores, such as Azure Table Storage.
We are explicitly not trying to build an abstraction layer that hides the type of data store you are targeting. The common patterns/components that apply to most data stores will be handled by the core framework. Things that are specific to particular types of data stores will be available as extensions that are included as part of the provider. For example, the concept of a model builder that allows you to configure your model will be part of the core framework. However, the ability to configure things such as cascade delete on a foreign key constraint will be included as extensions in the relational database provider.
In the TechEd session you can see a demo of EF7 being used to access Azure Table Storage starting at 56:45.
As we look at what we want to achieve in EF7 we’ve had to take a realistic look at our current code base. While it has served us well and allowed us to release some solid versions of EF in recent times, it is not really setup to achieve what we want to in EF7.
The EF code base has a long history, going back to the WinFS days, with parts of the code base being 10+ years old. The current code base makes extensive use of older APIs and design patterns. Many of the APIs that EF uses heavily are not available on the new platforms we want to target. In addition, the code base is monolithic in nature which makes it difficult to implement new features and increasingly harder to change things without breaking existing functionality.
When Entity Framework began life, it’s charter was more to do with the Entity Data Model vision rather than being a best-of-breed O/RM. As a result, there are many seldom used features and capabilities in the code base that hamper performance and complicate development, but are not feasible to remove due to the monolithic nature of the implementation. We also have a number of unintuitive behaviors that are engrained into the framework and hard to change or remove for the same reasons.
While using less resources is desirable on all platforms it becomes more prominent on devices as they typically have fewer resources than desktop and server machines. These concerns were not a driving factor when EF was designed and implemented. The current resource usage of EF hinders its ability to be a good data access offering on devices. We’ve done some investigation on lowering resource usage and found it to require architectural changes that require a very large amount of work. As we move toward cloud computing, low resource usage is also desirable as it allows greater density of applications on servers – and is often directly tied to billing.
EF7 will be a lightweight and extensible version of Entity Framework that just pulls forward the commonly used features. In addition, we’ll be able to include some commonly requested features that would have been difficult to implement in the existing code base, but can be included from the start in EF7.
We’ll be keeping the same patterns and concepts that you are used to in Entity Framework, except where there is a compelling reason to change them. You’ll see the same DbContext/DbSet based API but it will be built over building block components that are easy to replace or extend as needed – the same pattern we’ve used for some of the isolated components we’ve added in recent EF releases.
We will still continue to invest in EF6 while we work to make EF7 have better feature parity with EF6. In fact, we implemented the EF6.1 and EF6.1.1 releases while working on the EF7 code base.
Upgrade from EF6 to EF7 is a key scenario for us, both in terms of existing code and existing knowledge. We’ll be keeping the same concepts and patterns wherever it makes sense. The upgrade to EF7 will require some changes to your code. Our aim is that code that uses the core functionality of the DbContext API will upgrade easily, code that makes use of the lower level APIs in EF may require more complicated changes.
It’s early days, but we are underway with the EF7 implementation. We’re developing in the EntityFramework GitHub repository and have nightly builds available. We aren’t able to accept contributions just yet, but we will in the near future.
If you want to try out the nightly builds, just bear in mind that this is pre-alpha code and there is a lot of functionality that is partially implemented or still to be added. Visit our documentation on GitHub for more information on getting started with nightly builds.
We’ll keep you updated with more details on EF7 and the features we are implementing over the coming months.