Announcing the Plan for EF7

Jeremy Likness

December 15th, 202110 0

Today we are excited to share with you the plan for Entity Framework Core 7. This plan brings together input from many stakeholders and outlines where and how we intend to invest in Entity Framework Core 7 (EF Core 7). For brevity, EF Core 7.0 is also referred to as just EF7.

The plan is being tracked through GitHub dotnet/efcore repo issue #26994 and any updates will be posted there.

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.

To review the plans for other products, areas, and .NET 7 overall, visit and read the ThemesOf.Net.

General information

EF Core 7 is the next release after EF Core 6 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 will 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 on Windows.
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 the plan issue (#26994) if you believe we are missing something that is critical for EF7, or are focusing on the wrong areas.

Jeremy Likness Principal Program Manager - .NET Web Frameworks, .NET

10 comments

Harold Harkema December 15, 2021 1:56 pm 0

Please focus on stability. EF core has big issues with SqlClient. For example huge performance issues when ToListAsync is used with nvarchar(max) colmns.

Daniel Smith December 15, 2021 2:30 pm 0

The renaming of .NET Core 5 to simply .NET 5 was a very welcome simplification.

Can’t the unnecessary “core” part of the product name also be dropped for EF7 since it finally moves passed the EF6 numbering?

Rand Random December 16, 2021 3:35 am 0

Why is “Enhancements to System.Data: Better low-level data access to benefit all higher-level code.” a thing, instead of migrating to Microsoft.Data?
Microsoft.Data: https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/

Kalle Niemitalo December 16, 2021 7:49 am 0

If new virtual methods that minimize memory allocations are added to types like System.Data.Common.DbDataReader, they can then be overridden in Microsoft.Data.SqlClient and other providers, and libraries can use them without depending directly on Microsoft.Data.SqlClient. I expect they won’t be overridden in System.Data.SqlClient, though.

Aleksander Kovač December 16, 2021 4:45 am 0

The plan looks very exciting, good luck with the execution.

James Hancock December 16, 2021 5:41 am 0

Left outer join syntax so we don’t have to subject ourselves to the horrific syntax that is currently used.

Asad Mehmood January 6, 2022 12:10 pm 0
Hi @james, this syntax might interest you. This will result in simple left outer join query. If you remove DefaultIfEmpty(), the resultant query will be inner join
```
var query = (from a in context.Alpha
from b in context.Beta.Where(x=>x.Id == a.Id).DefaultIfEmpty()
select new {
a.Field1,
b.Field2
})
```

hitesh davey December 16, 2021 8:13 am 0

Suggestion: Pl, add the “BeforeExecute” event to trap and analyze all SQL/DDL/DML statements. This will also help us make changes to generated source statement(s) on the fly. VB6 ADO connection object had this event exposed and was very handy in many challenging scenarios.

Karl December 16, 2021 11:48 am 0

Please do some work on TransactionScope too, like making it AsyncDisposable

TECHWOLL January 3, 2022 4:15 am 0

Congratulations on planning and implementing your exciting program.

Discussion is closed. Login to edit/delete existing comments.

Harold Harkema December 15, 2021 1:56 pm 0

Please focus on stability. EF core has big issues with SqlClient. For example huge performance issues when ToListAsync is used with nvarchar(max) colmns.
Daniel Smith December 15, 2021 2:30 pm 0

The renaming of .NET Core 5 to simply .NET 5 was a very welcome simplification.

Can’t the unnecessary “core” part of the product name also be dropped for EF7 since it finally moves passed the EF6 numbering?
Rand Random December 16, 2021 3:35 am 0

Why is “Enhancements to System.Data: Better low-level data access to benefit all higher-level code.” a thing, instead of migrating to Microsoft.Data?
Microsoft.Data: https://devblogs.microsoft.com/dotnet/introducing-the-new-microsoftdatasqlclient/
- Kalle Niemitalo December 16, 2021 7:49 am 0
  
  If new virtual methods that minimize memory allocations are added to types like System.Data.Common.DbDataReader, they can then be overridden in Microsoft.Data.SqlClient and other providers, and libraries can use them without depending directly on Microsoft.Data.SqlClient. I expect they won’t be overridden in System.Data.SqlClient, though.
Aleksander Kovač December 16, 2021 4:45 am 0

The plan looks very exciting, good luck with the execution.
James Hancock December 16, 2021 5:41 am 0

Left outer join syntax so we don’t have to subject ourselves to the horrific syntax that is currently used.
- Asad Mehmood January 6, 2022 12:10 pm 0
  Hi @james, this syntax might interest you. This will result in simple left outer join query. If you remove DefaultIfEmpty(), the resultant query will be inner join
```
var query = (from a in context.Alpha
from b in context.Beta.Where(x=>x.Id == a.Id).DefaultIfEmpty()
select new {
a.Field1,
b.Field2
})
```
hitesh davey December 16, 2021 8:13 am 0

Suggestion: Pl, add the “BeforeExecute” event to trap and analyze all SQL/DDL/DML statements. This will also help us make changes to generated source statement(s) on the fly. VB6 ADO connection object had this event exposed and was very handy in many challenging scenarios.
Karl December 16, 2021 11:48 am 0

Please do some work on TransactionScope too, like making it AsyncDisposable
TECHWOLL January 3, 2022 4:15 am 0

Congratulations on planning and implementing your exciting program.

Announcing the Plan for EF7

General information