Plan for Entity Framework Core 7.0

Today we are excited to share with you the plan for Entity Framework Core 7.0. This issue contains a quick summary of the plan and acts as a place for you to leave feedback.

This plan brings together input from many stakeholders and outlines where and how we intend to invest in Entity Framework Core 7.0 (EF Core 7.0.) For brevity, EF Core 7.0 is also referred to as just EF7.

IMPORTANT This plan is not a commitment; it will evolve as we continue to learn throughout the release. Some things not currently planned for EF7 may get pulled in. Some things currently planned for EF7 may get punted out.

General information

EF Core 7.0 is the next release after EF Core 6.0 and is currently scheduled for release in November 2022 at the same time as .NET 7. There are no plans for an EF Core 6.1 release.

EF7 will align with the .NET support policy and will therefore not be a long-term support (LTS) release.

EF7 currently targets .NET 6. This may be updated to .NET 7 as we near the release. EF7 does not target any .NET Standard version; for more information see the future of .NET Standard. EF7 will not run on .NET Framework.

Themes

The large investments in EF7 will fall mainly under the following themes.

Highly requested features

As always, a major input into the planning process comes from votes (👍) for features on GitHub.

• JSON columns: Save and query into JSON-based documents stored in relational database columns.
• Bulk updates: Efficient, predicate-based updates for many database rows without loading data into memory.
• Lifecycle hooks: Allow applications to react when interesting things happen in EF code.
• Table-per-concrete-type (TPC) mapping: Map entities in a hierarchy to separate tables without taking the performance hit of TPT mapping.
• Map CUD operations to stored procedures: Use stored procedures to manage data modifications.
• Value objects: Applications can use DDD-style value objects in EF models.
• Support value generation when using value converters: DDD-style encapsulated key types can make full use of automatically generated key values.
• Raw SQL queries for unmapped types: Applications can execute more types of raw SQL query without dropping down to ADO.NET or using third-party libraries.
• Database scaffolding templates: The code generated by dotnet ef database scaffold can be fully customized.

.NET platforms and ecosystem

Much of the work planned for EF7 involves improving the data access experience for .NET across different platforms and domains. This involves work in EF Core where needed, but also work in other areas to ensure a great experience across .NET technologies.

• Distributed transactions: .NET Framework applications using distributed transactions can be ported to .NET 7.
• EF Core tooling: Ensure dotnet ef commands are easy to use and work with modern platforms and technologies.
• EF Core and graphical user interfaces: Make it easy to build data-bound graphical applications with EF Core.
• SqlServer.Core (Woodstar): Fast, fully managed access to SQL Server and Azure SQL for modern .NET applications.
• Azure Cosmos DB provider: Continue to make EF Core the easiest and most productive way to work with Azure Cosmos DB.
• Migrations experience: Make it easy to get started with migrations and later use them effectively in CI/CD pipelines.
• Trimming: Smaller applications that can be efficiently AOT compiled.
• Evolve System.Linq.Expression: Use modern C# language features in LINQ queries.
• Translate new LINQ operators: Use new LINQ operators when translating LINQ queries to SQL.
• Open telemetry for ADO.NET providers: Cross-platform, industry-standard telemetry that can be monitored in your tool of choice.
• Enhancements to System.Data: Better low-level data access to benefit all higher-level code.
• Research data access for cloud-native: Future evolution of .NET data access that supports modern approaches such as microservices and cloud native.

Clear path forward from EF6

EF Core has always supported many scenarios not covered by the legacy EF6 stack, as well as being generally much higher performing. However, EF6 has likewise supported scenarios not covered by EF Core. EF7 will add support for many of these scenarios, allowing more applications to port from legacy EF6 to EF7. At the same time, we are planning a comprehensive porting guide for applications moving from legacy EF6 to EF Core.

Performance

Great performance is a fundamental tenet of EF Core, lower-level data access, and indeed all of .NET. Every release includes significant work on improving performance.

• Performance of database inserts and updates: High performance database inserts and updates from EF Core
• TechEmpower composite score: High performing low-level data updates for all .NET applications.

Find out more and give feedback

This post is a brief summary of the full EF7 plan. Please see the full plan for more information.

Your feedback on planning is important. The best way to indicate the importance of an issue is to vote (👍) for that issue on GitHub. This data will then feed into the planning process for the next release.

In addition, please comment on this issue if you believe we are missing something that is critical for EF7, or are focusing on the wrong areas.

[benstevens48]

How about https://github.com/dotnet/efcore/issues/1387 (including/excluding specific properties when loading an entity from the database)? Together with bulk updates/deletes that’s the main thing that’s missing from EF Core for me.

[rcbellamy]

Honestly, for the remainder of the EF7 timeframe and the entirety of the EF8 timeframe, Microsoft’s only focus should be improving the documentation for the currently existing features. Any Microsoft-employed developer responsible for developing EF Core that is not qualified to author documentation in proper English (and some of the current documentation is from authors that are not so qualified) should either be focused on bug fixes or improving the performance of the existing API, or should be laid off. I cannot imagine what kind of stakeholders have any legitimate interest in further development of the API without better documentation of the already-existing API.

Furthermore, I am quite certain the God would not look kindly on any stakeholder allowing other “priorities” (for the EF Core team, that is) to get in the way of better documentation, so if Microsoft does encounter some stakeholder that it cares about whose representative is claiming that the EF Core developers should have “higher” priorities, I would strongly suggest that Microsoft speak to people at said stakeholder above that representative’s head about how important those other priorities really are.