Though separated from the .NET Core release cycle, EF Core is developing its 3.0 roadmap. Along with it are some important changes to the original Entity Framework.
Entity Framework 6.3 on .NET Core 3
First of all, Entity Framework is done. In terms of features and functionality, nothing new is planned for Entity Framework 6.x and it is highly unlikely there will ever be an Entity Framework 7.
That said, Entity Framework hasn’t been completely forgotten. Microsoft has recognized that porting legacy database code from EF 6 to EF Core isn’t necessarily easy, which makes it a roadblock to .NET Core adoption.
The current plan is to offer a partial version of Entity Framework that runs on .NET Core. This will require new database-specific providers. Furthermore, some features such as spatial data in SQL Server will not be supported.
The remaining items in this article apply to EF Core.
More Server-Side Queries
It can often be difficult, even impossible, to translate a LINQ query into a corresponding SQL query. Many ORMs deal with this problem simply by throwing a runtime exception when the translation fails, but EF Core attempts to be more forgiving. When it cannot fully comprehend a LINQ query, it partially translates it into SQL and then performs the remaining operations client-side. While this can result in very poor performance, many developers favor this over the query simply failing outright.
Diego B Vega writes,
In EF Core 3.0, we are planning to make profound changes to how our LINQ implementation works, and how we test it. The goals are to make it more robust (for example, to avoid breaking queries in patch releases), to be able to translate more expressions correctly into SQL, to generate efficient queries in more cases, and to prevent inefficient queries from going undetected.
NoSQL Support
For a long time there has been the desire for an ORM that seamlessly handles both SQL and NoSQL databases. Originally announced as part of the EF Core 2.1 roadmap, Microsoft is still attempting to introduce this capability. The new plan is to start offering Cosmo DB support in EF Core 3.0.
C# 8.0 support
EF Core 3.0 will be the first version to include C# 8 support. This mainly means the API will be upgraded to include nullable reference types and async streams. How this will be done is still being determined, as one of the goals for EF Core 3.0 is to remain a .NET Standard 2.0 library. This could cut it off from some C# 8 features.
Since .NET Framework will not be supporting all of the new C# 8 features, it is unlikely Entity Framework 6.3 will likewise be upgraded to include C# 8 support.
Better Support for Views
Unlike Entity Framework, EF Core cannot generate query types for views in the database. Query types are used for entities that can be read from, but not written to, the database. Normally this would be the result of querying a view, stored procedure, or table-valued function.
This oversight in the code generator is expected to be corrected in EF Core 3.0.
Many-to-many Relationships
In order to represent a many-to-many relationship in EF Core, currently you need a "join entity" that represents the mapping table. With the "property bag entities" feature, EF Core gets one step closer to eliminating this requirement.
This feature is about enabling entities that store data in indexed properties instead of regular properties, and also about being able to use instances of the same .NET class (potentially something as simple as a Dictionary<string, object>) to represent different entity types in the same EF Core model.
Note Entity Framework already supports many-to-many relationship without a join entity.
Features not on the EF Core 3.0 Roadmap
With a limited budget, not everything that been requested will make it into the roadmap. Here are some of the top contenders that didn’t make the cut.
Stored Procedures
First class support for stored procedures will not be offered in the EF Core 3.0 timeframe. The work-around using query types and raw SQL still apply in the meantime.
Table Per Type Inheritance
When tables are very wide with far too many columns, one technique to address the problem is Table Per Type inheritance. With this model, each row is identified as belonging to one of several subtypes. Each subtype gets its own table with just the columns that are unique to that subtype. Only columns that are common to all subtypes remain in the original table.
Currently table per type inheritance is supported by Entity Framework, but not EF Core. While it has been a commonly requested feature since at least 2015, it is also a contested one. For some it is viewed as an anti-pattern because, when misused, it can hurt performance.
Others contend table per type inheritance can dramatically improve performance, as the cost of joining the base and subtype table can be smaller than dealing with a single table that is very wide. Furthermore, real world databases already use this pattern and EF Core needs to be able to work with those existing databases.
A new argument is TPT inheritance isn’t needed in EF Core because it already exists in Entity Framework and EF is going to be ported to .NET Core. The rebuttable to this claim is people may need both TPT inheritance and a EF-Core only feature.
Visual Studio Designer
Diego B Vega writes,
We understand that a designer may be an important feature for some of our customers to adopt EF Core, but we don’t see much feedback indicating that it is more important than the other features in our backlog. It would be interesting to know if you tried code first development and if you are aware that of the tooling that can reverse engineer an existing database into an EF Core model.
Upsert
Upsert, the ability to conditionally insert or update a record, is considered a second-tier ORM feature. While not necessary, it is nice to have as it can reduce round-trips to the database and simplify code. However, it currently doesn’t fit the EF Core model. In part because the way it needs to be implemented varies widely between databases. Some have explicit, but unique, syntax. Others leverage the MERGE statement, which can be problematic as it isn’t necessarily atomic. There is also Jet/MS-Access, which cannot support upsert at all but can be simulated using multiple queries.
Upsert is currently being discussed as part of the Merge/Upsert/AddOrUpdate support thread on Github.
GraphQL
Implementing GraphQL is very difficult. The query language is surprisingly complex and even a partial implementation isn’t really feasible without a framework or library supporting it.
Microsoft did have a prototype for GraphQL using EF Core a few years ago that was never publicly released. And they are entertaining the idea of revisiting it in the future, though there are many GraphQL design questions to be answered.