EF7 - New Platforms, New Data Stores


 More detailed information about this effort is available on our team blog



Entity Framework (EF) is now a common data access technology for traditional client and server applications (WPF, WinForms, MVC, WebAPI, WebForms, WCF, etc.). We think there is value in providing the same programming model for data access on the remaining platforms where .NET development is common (primarily Windows Store and Windows Phone apps). This is especially true in areas where there is currently no good higher level framework for data access – as is the case with Windows Store.


We’ve hit a number of issues as we have looked at taking changes to our code base to allow it to be used on these platforms:

  • The EF code base has a long history going back to the WinFS days. It makes extensive use of older APIs and design patterns. It would be very expensive to pull all of this forward onto modern platforms.
  • 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. EF was not built with this in mind. In particular, memory usage was 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.

How this ties into the Cloud

Interestingly, the desire to reduce resource usage is also prominent as we move to cloud computing – especially in ‘Platform as a Service’ (Paas) scenarios. In a pay-per-play cloud environment the cost of running an application is closely associated with the amount of resources used by that application. This makes it especially important for applications running in the cloud to use fewer resources in order to correspondingly reduce costs.

EF currently uses a significant amount of resources, even for small models and simple data access. This doesn’t align well with a pay-per-play environment.

What are we doing

We are looking at providing a lighter weight version of EF that can be used across a wide variety of platforms. This effort is not about re-implementing the entire EF stack; the current stack contains a lot of APIs and features that are not especially useful and/or hardly ever used. The lighter weight version will be simplified so that it doesn’t contain these. Some examples of this simplification include just having the DbContext API (no ObjectContext API) and supporting a reduced set of mapping patterns.

Windows Store and Windows Phone

For Store and Phone applications we are initially just looking at local data access. SQLite is by far the most common database choice on devices so we will use that as the default database provider. We will continue to use a provider model though, so other database providers can be used.

In the future, things such as remote data access and online/offline syncing are areas we may look into. They are not part of our initial investigation though.

Last edited May 23, 2014 at 3:47 PM by RoMiller, version 10


M_Lyons10 Mar 11 at 10:17 PM 
So, when will SQL Server Data Access be included and available to UWP apps? The much touted VPN support is rather useless without the ability to get the data on the other side...

taherchhabra May 19, 2014 at 3:51 PM 
Currently i am developing a MultiTenant application where i have to write a where clause on each and every query to filter based on TenantId. (Though i have abstracted it in base repository) Can we have something like pluggable global filter on Dbcontext so that my Dbcontext gives rows based on a Global TenantId Filter. I am saying this in reference to single database single schema multitenant approach

ajcvickers May 14, 2014 at 4:28 PM 
Just an FYI for @shiva_mn and others: more details on EF7 (EF/Everywhere) can be found on the project page in GitHub which was made public yesterday: https://github.com/aspnet/EntityFramework Mostly we just have source code up for now, but other kinds of info will be added as we progress.

arthernan May 14, 2014 at 2:26 PM 
EF is right in between of being a language feature and a framework. Any movement towards making it look more like a language would be an improvement to me. I hope you are able to leverage Roslyn to improve it's performance and footprint.

shiva_mn May 14, 2014 at 8:50 AM 
Any news on EF Everywhere progress?

RogerAlsing May 12, 2014 at 8:01 PM 
So if I get this right, you are splitting the domain model management stuff from the actual persistence stuff, right?

The core handles interception for lazy load, dirtytracking, identity mapping etc.
and the ORM part is the addon?

leisenstein May 5, 2014 at 2:22 PM 
I would love to see this too. I'd like to see something light-weight, dead simple and relies on convention over configuration. Make it easy to map existing DBs to code.

Put an emphasis on common workflows like basic CRUD, running SQL statements and stored procs. Just keep it simple. If you've ever seen GORM (from Grails), they do a good job on this.

Demirag Apr 29, 2014 at 4:20 PM 
I think this is a great idea. In my opinion, this lighter version needs to be simple and effective as Linq-to-sql. I dont have any statistics about how many percent actually using EF with database servers other than SqlServer but EF suffers to support all of those different platforms. For developers like me Linq-to-sql was far superior to EF in the beginning but later on microsoft decided to continue development only for EF so we had to migrate our datalayer sooner or later. Simple things that we used to write in Linq-to-sql is now sometimes really complex in EF. ( all those “cannot be translated into a store expression” exceptions) Also, after all those years, EF still has performance weaknesses against Linq-to-sql.

I am really looking forward to see brand new version of EF that we can use in real world world applications without worrying about the performance. For real world applications providing the best performance is a mess with current EF version, always trying different things to get the best performance. At the end it is not a time saver anymore.

So in my opinion, just keep the most used features we use and get rid of all complex stuff that causes performance reduction. For example, code-first approach is very cool feature , allowing developers to jump start development and having a chance to switch to db-first in the future. On the other hand Entity-mapping might be very powerfull and flexible but I guess many of us do not need that, we have 1-1 same schema with our databases and making complex bindings by defining our business objects.

RoMiller Apr 8, 2014 at 9:53 PM 
@iLMaX - That's pretty much the approach we are taking - we've been using the term 'pay per play' to describe this. We will have a top level experience that ties all the core pieces together (i.e. unit of work pattern, change tracking, etc.) and then other things (like mapping to a relational database) will be extensions on this core.

iLMaX Apr 7, 2014 at 9:56 PM 
What I really would love to see in this "lighter" version of EF would be a really small ORM which handles only basic scenarios but with a great level of extensibility. There are tons of features in EF but not every feature is often used so I really love to see all those "advanced features" pulled off the code base, let me do an example to further explain my point of view.

Entity mapping in EF is very powerful and allows a great level of flexibility but this is not always worth paying for because 9 times out of 10 simple mapping (1 entity to 1 table) is used, so I really love to see only entity basic mapping and provide a set of extension points to allow plugging in custom mapping scenarios. For example this could be achieved via a separate nuget package so you only install it only when it's really needed.

Now EF is a giant, because of all the things it handles, but we pay for all those features even when those aren't used. Creating a smaller runtime with a limited set of capabilities will allow to reduce the memory footprint of EF (and this is really important in a mobile app) and improve the speed, alongside a richer extensibility API allows the developer to bridge the gap with the limited capabilities and allow the "pay for what you use" scenario.

This is really what I love to see in "lighter" version and hopefully the vNext of EF.

RoMiller Mar 12, 2014 at 5:37 PM 
@Brisse07 - we wouldn't necessarily support reusing the same instance of the model while targeting a different schema... but reducing memory usage is one of the key goals.

@SSaurus - We want to keep a lot of the same API patterns since we think there is a lot of goodness in the DbContext API. The philosophy would be that we only change something if there is a compelling reason to do so. Of course, this only applies to the functionality/features that exist in the light weight version. This would make transitioning to 'EF Everywhere' easy - whether that's moving a code base to use the lighter weight version or just transferring your knowledge of EF.

Our plan is to make EF Everywhere run everywhere... including where the full stack current runs.

@SSaurus & @fujiy - Totally here you on the split code base thing... it's definitely not a decision we are taking lightly.

@compupc1 - This is definitely a valid concern. Although this light weight version of EF would still very much be EF, we aren't planning to pretend that it's exactly the same thing as the current types. We originally looked at refactoring the existing code base, but it's just not feasible to do given the complexity, design, and far-reaching impact of legacy/seldom-used features.

Brisse07 Feb 17, 2014 at 5:14 PM 
I am working on a SAAS application and honestly i am surprised that each context use according to my NOT scientific measurement around 15mb for each Context. So bad considering its the same context/model i am using for for every application. Why the h... can it be so hard to make it just simple and make it possible to reuse the same context with different schema name.

Besides that i really love Entity Framework...

Is Entity Framework Everywhere version addressing this issue?

SSaurus Feb 16, 2014 at 4:35 AM 
Two code bases would worry me. I think you should provide a migration path from the full EF to EF Everywhere and it should run on all platforms even those that support the full EF.

compupc1 Feb 9, 2014 at 3:22 AM 
I think this is a great idea in principle, but I am worried about the subtle "gotchas" that come with different versions of the same thing. In the UI world, having four XAML platforms that are "kinda the same but not really" is a source of incredible frustration. In 2014 it would be a shame to introduce the same kind of frustration for EF, especially when people are trying to share more code between client and server, between platforms, etc.

I wonder if there couldn't be some sort of "core" EF that would be usable everywhere (client, server, portable libraries, etc.). The advanced APIs could then use and expand upon the core, and would require the full .NET profile. Obviously this might mean some refactoring of existing code destined for the core, but it wouldn't be as expensive as refactoring everything.

fujiy Jan 28, 2014 at 12:57 AM 
I am a little worried about maintaining two code bases