The official source of information on Managed Providers, DataSet & Entity Framework from Microsoft
We all know, you don’t get to write software in a vacuum. Aside from the technical task we are trying to achieve there are things such as dependencies, stakeholders, release dates, etc. that impact the order and priority of tasks we do. In this post we wanted to share the top factors influencing the features and scenarios we focus on first.
Up until recently we’ve been focused on validating our “New Platforms, New Data Stores” vision for EF7. This has meant building out a core framework, experimenting with patterns to support data stores with different capabilities, and implementing providers to validate our work.
In terms of data stores, we have experimented with SQL Server, SQLite, InMemory, Azure Table Storage, and Redis providers. We’ve also had discussions with other folks looking at DocumentDB, SQL Compact, and MongoDB providers.
For platforms, we have targeted traditional .NET Framework applications (WPF, WinForms, Console, and ASP.NET 4), Phone/Store/Universal, and ASP.NET 5 (a.k.a ASP.NET vNext).
The vision for EF7 is “a core framework that handles concepts common to most data stores with provider specific extensions that become available when you target a specific provider”. At this stage we feel confident that our architecture works well for our initial scenarios/providers and can evolve to accommodate future requirements.
Now that we are confident we are building the right thing, it’s time to start working towards a product that developers can use to write real applications with.
This means we need to focus on tasks such as completing functionality, improving quality, ensuring performance, adding logging, exploring usability, etc.
One approach to this would be to plug away until we have a production ready product for all providers and platforms that has all the standard features that we expect from an O/RM (of course, with plenty of previews along the way). If we operated in a vacuum, this is the approach our team would choose to take as it would mean we would launch with the best possible product. However, in the real world we have a series of partners and commitments that mean we need to focus on meeting these goals in incremental steps.
Our team’s top commitment is to provide a data access stack for ASP.NET 5. Because ASP.NET 5 allows apps to target CoreCLR, the existing EF6.x product cannot provide this functionality (as it does not run on CoreCLR and it is not feasible to update it to do so). Within ASP.NET 5 our primary focus is on SQL Server, and then PostgreSQL to support the standard Mac/Linux environment.
Because ASP.NET 5 applications can also target the full .NET Framework, fulfilling our commitments to ASP.NET 5 will also allow EF7 to be used in other applications that target full .NET (WPF, WinForms, Console, and ASP.NET 4).
After fulfilling our ASP.NET 5 commitments, the other priorities of our team are as follows. These are in no particular order and we will likely work on them in parallel.
To meet the dates for the initial release of ASP.NET 5 we are going to have to scope the functionality of EF7 to exclude some features that we would consider basic O/RM functionality. Examples of this include lazy loading and inheritance mapping patterns.
Because of this, we won’t be pushing EF7 as the ‘go-to release’ for all platforms at the time of initial ASP.NET 5 release. More details on this later in the post.
In order to focus on our top priorities we are going to move several providers to a separate branch that we will not always keep updated with the latest changes. The packages will also not be published as part of nightly builds or pre-releases to NuGet.org. The impacted providers are SQLite, Azure Table Storage, and Redis. This will allow us to iterate on the core framework without the overhead of keeping multiple providers and their tests up-to-date as we go through various interim stages of the core framework.
Once we have stabilized the core and the code churn reduces, we will bring back the additional providers to validate the core framework again and begin working towards an initial release of these providers.
One important implication is that the SQLite provider will temporarily not be kept up-to-date or published in our nightly builds. This temporarily removes the ability to target Phone/Store applications during this period.
Scoping features and removing some providers will allow us to focus on the following activities for the initial ASP.NET 5 release.
As previously mentioned, 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.
Given that ASP.NET 5 is in the same ‘part v1 and part vNext’ position as EF, the missing features will be less of an issue. We will of course be working to make them available ASAP.
We are discussing ways to make this clearer when it comes time to ship a stable version of the EntityFramework package to support ASP.NET 5. We haven’t locked on the details yet (and won’t until we get closer to release) but some options we are considering are:
To ensure we meet our primary commitments to ASP.NET 5 we are going to be focusing on rounding out the existing features and the SQL Server provider for EF7.
This means scoping out some very important features and we will not be encouraging folks to transition from EF6 to EF7 until these features are added.
We will temporarily be suspending work on SQLite, Azure Table Storage, and Redis providers and they will not be included in nightly builds. These are important scenarios for us and we will re-enable them as soon as we meet our ASP.NET 5 commitments.
We understand this is disappointing to many folks. Most notably, temporarily disabling Phone/Store was a painful decision for us to make. Our team would love to work in isolation and make EF7 a complete and polished product on many providers and platforms before initial release. Unfortunately that is not the case, so we’re working to meet our commitments while still delivering on the all up vision in a reasonable time frame.