针对 Entity Framework Core 7.0 的计划

如 规划过程中所述，我们已将利益干系人的意见收集到 Entity Framework Core 7.0 (EF Core 7.0.) 的计划中，为简洁起见，EF Core 7.0 也称为 EF7。

 重要

此计划不是承诺;随着我们在整个版本中继续学习，它将不断发展。 目前未计划用于 EF7 的一些事项可能会被拉入。 目前计划用于 EF7 的一些事情可能会被淘汰。

常规信息

EF Core 7.0 是 EF Core 6.0 之后的下一个版本，目前计划于 2022 年 11 月发布，同时为 .NET 7。 EF Core 6.1 版本没有计划。

受支持的平台

EF7 目前面向 .NET 6。 这可能会在版本接近时更新到 .NET 7。 EF7 不面向任何 .NET Standard 版本; EF7 不会在.NET Framework上运行。

EF7 将与 .NET 支持策略 保持一致，因此 不会 是 LTS () 版本的长期支持。

中断性变更

EF7 将包含少量 重大更改 ，因为我们继续发展 EF Core 和 .NET 平台。 我们的目标是尽可能减少中断性变更。

主题

EF7 的大型投资主要属于以下主题：

• 被强烈要求的功能
• NET 平台和生态系统
• 从 EF6 清除路径转发
• 性能

下面详细介绍了其中每个主题。 可以在 EF Core 两周更新中跟踪每个主题的高级状态。 请使用任何反馈或建议就GitHub问题 #26994  https://github.com/dotnet/efcore/issues/26994发表评论。

主题：高请求的功能

与往常一样，规划过程中的主要投入来自GitHub功能 (👍) 投票。 除了其他因素外，我们还计划为 EF7 处理以下要求很高的功能。

JSON 列

按 问题 #4021 跟踪：将数据库中存储的 JSON 值映射到 EF 属性 https://github.com/dotnet/efcore/issues/4021

价值主张：保存和查询存储在关系数据库列中的基于 JSON 的文档。

此功能将为 JSON 支持引入可由任何数据库提供程序实现的通用机制和模式。 我们将与社区合作来调整 Npgsql 和 Pomelo MySQL 的现有实现，并添加对 SQL Server 和 SQLite 的支持。

批量更新

问题 #795 跟踪：批量 (，即基于集) 的 CUD 操作 (，无需将数据加载到内存) https://github.com/dotnet/efcore/issues/795

价值主张：许多数据库行的基于谓词的高效更新，无需将数据加载到内存中。

更改跟踪 后跟 SaveChanges 是 EF Core 中用于插入、更新和删除实体的主要机制。 此机制可确保将数据库操作排序以满足约束，并且跟踪的实体与对数据库所做的更改保持同步。 但是，它要求数据库往返将实体加载到内存中，以便创建适当的数据库命令，然后执行这些命令的数据库往返。

相比之下，批量更新或基于集的更新涉及定义对数据库的更改，然后执行这些更改，而无需先将实体加载到内存中。 这比跟踪的更新要快得多，尤其是在必须对许多不同的实体/行应用相同的修改时。

对于 EF7，我们计划实现批量更新和删除 (，但不插入) 。 请注意，批量更新与批处理更新不同。 EF Core 在向 SaveChanges数据库发送更新时，已将对许多跟踪实体的更改合并成批。

生命周期挂钩

按 问题 #626 跟踪：生命周期挂钩 https://github.com/dotnet/efcore/issues/626

价值主张：允许应用程序在 EF 代码中发生有趣的事情时做出反应。

每当实体、属性、关系、查询、上下文实例和其他 EF 构造出现某些有趣的条件或操作时，生命周期挂钩都允许通知应用程序或库。 我们在以前版本的 EF Core 上实现了许多生命周期挂钩，包括各种拦截器和事件。 对于 EF7，我们计划添加重要的缺失挂钩。 例如，创建实体实例后用于操作实体实例的挂钩，通常称为 ObjectMaterialized。

每个具体类型的表 (TPC) 映射

按 问题 #3170 跟踪：TPC 继承映射模式 https://github.com/dotnet/efcore/issues/3170

价值主张：将层次结构中的实体映射到单独的表，而不会达到 TPT 映射的性能。

EF Core 支持 .NET 继承层次结构 的按表 (TPH) 和 每种类型的表 (TPT) 映射。 每个具体类型的表 (TPC) 映射类似于 TPT 映射，因为层次结构中的每个实体类型都映射到不同的数据库表。 但是，虽然 TPT 将基类型中的属性映射到基类型的表中的列，但 TPC 会将基类型的属性映射到与要映射的实际混凝土类型相同的表。 这可以显著提高性能，因为查询特定类型时不需要联接多个表。 这牺牲了数据非规范化，因为列在映射到层次结构中每个具体类型的表中重复。

TPC 映射的工作还涵盖了更常规 的实体拆分，并支持 在 TPT、TPC 或实体拆分中为每个表指定不同的分面。

将 CUD 操作映射到存储过程

按 问题 #245 跟踪：将插入、更新和删除 (CUD 操作) 映射到存储过程 https://github.com/dotnet/efcore/issues/245

价值主张：使用存储过程管理数据修改。

EF Core 已经支持从存储过程查询数据。 此功能将允许将插入、更新和删除生成的 SaveChanges 插入、更新和删除映射到数据库中的存储过程。

值对象

由 问题 #9906 跟踪：使用 C# 结构或类作为值对象 https://github.com/dotnet/efcore/issues/9906

价值主张：应用程序可以在 EF 模型中使用 DDD 样式的值对象。

以前，拥有实体的团队视图（旨在提供聚合支持）也是值对象的合理近似值。 经验表明事实并非如此。 因此，在 EF7 中，我们计划引入更好的体验，重点介绍域驱动设计中值对象的需求。 此方法将基于值转换器而不是拥有的实体。

这项工作最初作用的范围是允许映射到多个列的值转换器。 我们可能会根据发布期间的反馈引入其他支持。

使用值转换器时支持值生成

问题 #11597 跟踪：支持使用转换器生成更多类型的值 https://github.com/dotnet/efcore/issues/11597

值主张：DDD 样式封装的键类型可以充分利用自动生成的键值。

EF Core 6.0 允许更多类型的值生成与通过 值转换器映射的键一起使用。 我们计划在 EF7 中通用化和扩展此支持。

未映射类型的原始SQL查询

由问题 #10753 跟踪：支持原始SQL查询，而无需为结果定义实体类型 https://github.com/dotnet/efcore/issues/10753

价值主张：应用程序可以执行更多类型的原始SQL查询，而无需删除到 ADO.NET 或使用第三方库。

当前原始SQL查询必须返回模型中的类型（无论是否定义键）。 在 EF7 中，我们计划允许直接返回 EF 模型中不包含的类型的原始SQL查询。

此处的工作还将介绍返回简单/标量类型的原始SQL查询，例如Guid，DateTime和intstring。

数据库基架模板

由 问题 #4038 跟踪：用于从现有数据库基架实体类型和 DbContext 基架的代码模板 https://github.com/dotnet/efcore/issues/4038

价值主张：可以完全自定义由其 dotnet ef database scaffold 生成的代码。

我们经常收到在从现有数据库中搭建基架 (反向工程) 时生成的代码调整请求。 我们计划通过支持生成的实体类型的 DbContextT4 模板，在 EF7 中解决这些请求。 开发人员将能够自定义标准模板，或从头开始创建新模板。

主题：.NET 平台和生态系统

EF7 计划的大部分工作都涉及在不同平台和域中改进 .NET 的数据访问体验。 这涉及到在需要的情况下在 EF Core 中工作，但也可在其他领域工作，以确保跨 .NET 技术提供出色的体验。 我们将重点介绍 EF7 版本的以下平台/技术：

• .NET MAUI
• ASP.NET Core
• Azure Synapse
• Blazor 服务器
• Blazor WebAssembly
• Windows 窗体
• Windows Presentation Foundation (WPF)

此列表基于许多因素，包括客户数据、战略方向和可用资源。 下面概述了我们将为这些平台处理的一般领域。

分布式事务

在 dotnet/runtime 中按问题 #715 进行跟踪：在 System.Transactions 中实现分布式/提升的事务 https://github.com/dotnet/runtime/issues/715

价值主张：.NET Framework使用分布式事务的应用程序可以移植到 .NET 7。

System.Transactions.NET Framework中的库包含本机代码，该代码使用 Windows 分布式事务协调器 (DTC) 来支持分布式事务。 此代码从未移植到 .NET Core。 在 .NET 7 时间范围内，我们计划调查并开始将此功能引入新式 .NET 的过程。 这最初仅适用于Windows，并且仅支持 ADO.NET 提供程序还支持分布式事务的数据库方案。 .NET 7 不支持分布式事务的其他用途，例如在 WCF 中。 根据反馈和成本，我们可以在将来的版本中实现对其他方案和/或非Windows平台的支持。

EF Core 工具

按 问题跟踪 #26798：现代化 EF Core 工具 https://github.com/dotnet/efcore/issues/26798

价值主张： dotnet ef 命令易于使用，适用于现代平台和技术。

自首次在 EF Core 1.0 中引入迁移工具、数据库基架等工具以来，.NET 平台已不断发展。 在 EF7 中，我们计划更新工具体系结构，以更好地支持 .NET MAUI 等新平台，并简化多个项目等领域的流程。 这包括在出现问题时提供更好的反馈、更好地与日志记录、性能和新 糖的集成。

EF Core 和图形用户界面

问题 #26799：改善数据绑定和图形界面的体验 https://github.com/dotnet/efcore/issues/26799

价值主张：使用 EF Core 轻松构建数据绑定图形应用程序。

EF Core 旨在很好地处理数据绑定方案，例如Windows 窗体和 .NET MAUI 中的方案。 但是，在这些技术之间连接点并不总是容易的。 对于 EF7，我们计划在 EF Core 和 Visual Studio 中改进工作体验，以便更轻松地使用 EF Core 生成数据绑定应用程序。

SqlServer.Core (Woodstar)

在 .NET Data Lab 存储库中进行跟踪

价值主张：快速、完全托管地访问新式 .NET 应用程序的SQL Server和Azure SQL。

Microsoft.Data.SqlClient 是 SQL Server 的功能齐全的 ADO.NET 数据库提供程序。 它在 .NET Core 和 .NET Framework 上都支持多种 SQL Server 功能。 不过，它也是一个较大的旧代码库，其行为之间存在很多复杂的交互。 这使得很难调查可以使用较新的 .NET Core 功能实现的潜在收益。

我们去年开始了一个项目，俗称"Woodstar"，以调查 .NET 的高性能SQL Server驱动程序的潜力。 我们计划在 EF7 时间范围内对该项目进行重大进一步投资。

 重要

对 Microsoft.Data.SqlClient 的投资不会改变。 建议使用 EF Core 和不使用 EF Core 连接到SQL Server和Azure SQL。 引入新的 SQL Server 功能后，它将继续支持新功能。

Azure Cosmos DB 提供程序

通过标记为"area-cosmos"和 7.0 里程碑的问题进行跟踪

价值主张：继续使 EF Core 成为使用 Azure Cosmos DB 的最简单、最高效的方式。

我们对 6.0 版本的 EF Core Cosmos 数据库提供程序进行了重大改进。 这些改进为从 EF Core 使用 Azure Cosmos DB 创造了一流的体验，这反映在采用方面的显著增长。 我们计划继续在 EF7 中保持这种势头，并进一步Cosmos提供程序增强功能：

• 问题 #16146：支持聚合运算符 https://github.com/dotnet/efcore/issues/16146
• 问题 #17306：允许使用自定义 JSON 序列化程序 https://github.com/dotnet/efcore/issues/17306
• 问题 #17670：尽可能在查询中转换非持久化属性 https://github.com/dotnet/efcore/issues/17670
• 问题 #19944：支持触发器执行 https://github.com/dotnet/efcore/issues/19944
• 问题 #20350：在更多查询中检测分区键筛选器 https://github.com/dotnet/efcore/issues/20350
• 问题 #20910：添加字符串的翻译。比较Cosmos https://github.com/dotnet/efcore/issues/20910
• 问题 #23538：在翻译过程中改进查询树 https://github.com/dotnet/efcore/issues/23538
• 问题 #24571：允许在 Skip 和 Take 之后终止运算符 https://github.com/dotnet/efcore/issues/24571
• 问题 #24513：添加对 maxItemCount (分页的支持) https://github.com/dotnet/efcore/issues/24513
• 问题 #25700：转换集合的长度/计数 https://github.com/dotnet/efcore/issues/25700
• 问题 #25701：将索引转换为集合 https://github.com/dotnet/efcore/issues/25701
• 问题 #26478：实现Cosmos拦截器 https://github.com/dotnet/efcore/issues/26478
• 问题 #26491：通过 ClientSecretCredential 支持 AAD RBAC https://github.com/dotnet/efcore/issues/26491

请确保为所需的Cosmos提供商功能投票 (👍) ，以便我们可以评估投资最有利的位置。

迁移体验

受 问题 #22946 跟踪：数据库迁移改进 https://github.com/dotnet/efcore/issues/22946

价值主张：可以轻松开始迁移，稍后在 CI/CD 管道中有效地使用这些迁移。

EF Core 6.0 引入了 迁移捆绑包，显著改进了持续集成和部署系统中云原生应用程序和数据库部署的体验。 在 EF7 中，我们计划根据客户反馈在此领域进行其他改进。 例如，我们计划支持 在单个事务中执行所有迁移 ，以便在出现问题时更轻松地恢复。

此外，我们计划改进开发人员开始迁移的体验。 这包括能够在学习或开始项目时自动创建数据库，然后在项目成熟时 轻松切换到托管迁移 。 或者，对于具有现有数据库的项目，我们计划轻松地创建初始 EF 模型，然后 切换到使用迁移管理数据库 。

新式 .NET

随着 .NET 的不断发展，我们希望确保访问数据仍然是一种出色的体验。 为了促进这一点，我们计划在 EF7 期间在三个方面取得进展。

修剪

受问题 #21894 跟踪：改进 EF Core 应用的修整支持以减少应用程序大小 https://github.com/dotnet/efcore/issues/21894

价值主张：可以高效编译 AOT 的较小应用程序。

EF Core 执行大量的运行时代码生成。 对于依赖链接器树握手（如 Xamarin 和 Blazor）的应用模型以及不允许动态编译的平台（如 iOS）来说，这非常困难。 我们计划大大改进 EF7 中未使用代码的修整。 这将在使用 EF Core 时促进较小的程序集大小，从而帮助部署和提前 (AOT) 编译效率更高。

演进 System.Linq.Expression

价值主张：在 LINQ 查询中使用新式 C# 语言功能。

我们正在与 Roslyn 团队合作，制定一个计划，以允许在 LINQ 表达式中使用更多 C# 功能。 这是正在进行的工作，大部分将在 EF Core 存储库外部跟踪。

转换新的 LINQ 运算符

受问题 #25570 跟踪：支持新的 .NET LINQ 功能 https://github.com/dotnet/efcore/issues/25570

价值主张：将 LINQ 查询转换为SQL时使用新的 LINQ 运算符。

新的 LINQ 运算符最近已添加到 BCL 中，我们预计未来将增加更多。 问题 #25570  https://github.com/dotnet/efcore/issues/25570跟踪将这些支持添加到 EF7 LINQ 提供程序。 添加新的 LINQ 运算符时，将更新此问题。 与所有现有 LINQ 运算符一样，仅当运算符对数据库进行合理且有用的翻译时，我们才会添加支持。

打开 ADO.NET 提供程序的遥测数据

按问题 #22336 进行跟踪：针对数据库跟踪的 DiagnosticSource/OpenTelemetry 进行标准化 https://github.com/dotnet/runtime/issues/22336

价值主张：可在所选工具中监视的跨平台行业标准遥测数据。

开放遥测 是 Cloud Native Foundation 的一项计划，旨在培养云原生软件的常见遥测机制。 对于数据库，这包括建立数据库客户端遥测标准。 我们计划在 EF7 时间范围内执行工作，以帮助将开放遥测数据引入 .NET 生态系统中的 ADO.NET 提供程序。 这包括与社区合作，了解 开放源代码 MySQL 和 Npgsql 提供程序以及 Microsoft.Data.Sqlite。 我们还将联系其他提供商，我们鼓励 ADO.NET 提供商的维护人员联系（如果感兴趣）。

对 System.Data 进行改进

通过 7.0 里程碑中标记的 area-System.Data dotnet\runtime 存储库中的问题进行跟踪

价值主张：更好的低级别数据访问，使所有更高级别的代码受益。

与每个版本一样，我们打算探索改进。NET 的低级别数据库访问 API System.Data。 我们将重点介绍性能改进 (，例如，通过使用 API) 时消除装箱，减少内存分配，以及一些可用性改进。

根据可行性，稍后将确定精确改进的范围。

研究云原生数据访问

价值主张：支持现代方法（如微服务和云原生）的 .NET 数据访问的未来演变。

在 EF7 时间范围内，我们计划研究跨 .NET 平台进行数据访问的新式方法，尤其是在微服务和云原生应用程序中。 这项研究将有助于推动未来对 .NET 的数据访问技术的投资。

主题：从 EF6 清除路径向前

Docs 问题 #1180 跟踪：提供从 EF6 移植的更完整的指南 https://github.com/dotnet/EntityFramework.Docs/issues/1180

价值主张：轻松将应用程序从 EF6 移动到 EF7。

EF Core 始终 支持旧版 EF6 堆栈未涵盖的许多方案，而且通常性能要高得多。 但是，EF6 同样支持 EF Core 未涵盖的方案。 EF7 将添加对其中许多方案的支持，允许更多应用程序从旧版 EF6 移植到 EF7。 同时，我们计划针对从旧版 EF6 迁移到 EF Core 的应用程序制定 全面的移植指南 。

此主题中的大部分工作与上述工作重叠。 一些更重要的工作项包括：

• 问题 #214：向应用程序公开模型生成约定 https://github.com/dotnet/efcore/issues/214
• 问题 #245：将插入、更新和删除 (CUD 操作) 映射到存储过程 https://github.com/dotnet/efcore/issues/245
• 问题 #620：实体拆分支持 https://github.com/dotnet/efcore/issues/620
• 问题 #3170：TPC 继承映射模式 https://github.com/dotnet/efcore/issues/3170
• 问题 #3864：通过阴影导航支持单向多对多关系 https://github.com/dotnet/efcore/issues/3864
• 问题 #4038：用于从现有数据库基架实体类型和 DbContext 基架的代码模板 https://github.com/dotnet/efcore/issues/4038
• 问题 #10753：支持原始SQL查询，而无需为结果定义实体类型 https://github.com/dotnet/efcore/issues/10753
• 问题 #11003：对复合主键的 KeyAttribute 支持 https://github.com/dotnet/efcore/issues/11003
• 问题 #11624：支持基本类型（如 Guid、DateTime 和 int）的原始SQL查询 https://github.com/dotnet/efcore/issues/11624
• 问题 #15911：实现 ObjectMaterialized 事件 https://github.com/dotnet/efcore/issues/15911
• 问题 #17653：对 GroupBy entityType 的支持 https://github.com/dotnet/efcore/issues/17653
• 问题 #19929：在最终运算符时支持 GroupBy https://github.com/dotnet/efcore/issues/19929
• 问题 #19930：在最终查询运算符时支持 GroupJoin https://github.com/dotnet/efcore/issues/19930
• 问题 #26626：将 EF6 用作 EF Core 查询过程测试的 oracle https://github.com/dotnet/efcore/issues/26626

此外，我们计划在旧版 EF6 GitHub存储库上明确表示，我们不计划在 EF6 上执行任何未来的工作。 例外情况是，我们计划添加对将 EF6 与 Microsoft.Data.SqlClient 配合使用的支持。 这仅限于运行时支持。 在 Visual Studio 中使用 EF6 设计器仍需要 System.Data.SqlClient。

请注意，EF Core 与 EF6 具有基本不同的体系结构。 具体而言，它不使用实体数据模型 (EDM) 规范。 这意味着 EF Core 中永远不会支持某些功能，如 EDMX 和 EntitySQL。

主题：性能

出色的性能是 EF Core、较低级别数据访问和所有 .NET 的基本原则。 每个版本都包含改进性能的重要工作。 与往常一样，此主题将涉及大量迭代调查，然后告知我们重点资源的位置。

数据库插入和更新的性能

由 问题 26797 跟踪：改进更改跟踪和更新性能 https://github.com/dotnet/efcore/issues/26797

价值主张：高性能数据库从 EF Core 插入和更新。

在过去几个版本中，我们专注于提高非跟踪查询的 EF Core 性能。 对于 EF7，我们计划专注于与数据库插入和更新相关的性能。 这包括更改跟踪查询的性能 DetectChanges、插入和更新命令的性能以及发送到数据库的更新命令的性能。

这项工作的一部分包括实现 基于集的批量 () 更新，该更新作为高度请求的功能进行跟踪。 但是，我们还计划使用 SaveChanges改进传统更新的性能。

TechEmpower 复合分数

第 26796 期跟踪：提高 TechEmpower 复合分数的性能 https://github.com/dotnet/efcore/issues/26796

价值主张：所有 .NET 应用程序的高性能低级别数据更新。

几年来，我们一直在 .NET 上针对 PostgreSQL 数据库运行行业标准的 TechEmpower 基准。 在最近几个版本中，我们显著提高了低级别数据访问和 EF Core 的 财富基准 。

在 EF7 时间范围内，我们计划专门针对 TechEmpower 复合分数的改进。 这将测量范围更广的方案的性能。

其他功能

跟踪 7.0 里程碑中标记 type-enhancement 的问题 https://github.com/dotnet/efcore/issues?q=is%3Aopen+is%3Aissue+milestone%3A7.0.0+label%3Atype-enhancement

价值主张：持续改进 EF Core 以满足现有和不断发展的应用程序要求。

计划为 EF 7.0 提供的其他功能包括但不限于：

• 问题 #14545：设计：现代化生成的 C# https://github.com/dotnet/efcore/issues/14545
• 问题 #15762：提供从数据库上应用的最新脚本到代码库中的最新脚本的简单方法 https://github.com/dotnet/efcore/issues/15762
• 问题 #16406：完全接受特定于提供程序的迁移 https://github.com/dotnet/efcore/issues/16406
• 问题 #18844：SQLite：翻译 TimeSpan 成员 https://github.com/dotnet/efcore/issues/18844
• 问题 #18950：在迁移和模型快照中启用可为 null 性 https://github.com/dotnet/efcore/issues/18950
• 问题 #18990：使用来自 ADO.NET 的新批处理 API https://github.com/dotnet/efcore/issues/18990
• 问题 #21615：dotnet-ef 数据库更新 -1 (最新迁移) https://github.com/dotnet/efcore/issues/21615
• 问题 #21995：为尚未应用于给定数据库的所有迁移生成脚本 https://github.com/dotnet/efcore/issues/21995
• 问题 #22138：升级到 SpatiaLite 5 https://github.com/dotnet/efcore/issues/22138
• 问题 #23085：在调用 ConnectionOpening 之前不要检查连接字符串 https://github.com/dotnet/efcore/issues/23085
• 问题 #24685：允许值转换器更改列的可为 null 性 https://github.com/dotnet/efcore/issues/24685
• 问题 #25103：SQLite：翻译更多 DateOnly 和 TimeOnly 成员 https://github.com/dotnet/efcore/issues/25103
• 问题 #25872：提供有关迁移捆绑包的详细信息 https://github.com/dotnet/efcore/issues/25872
• 问题 #26155：用于获取上次迁移的迁移脚本的 Sugar https://github.com/dotnet/efcore/issues/26155
• 问题 #26417：重新访问日志记录中的异常和堆栈跟踪报告 https://github.com/dotnet/efcore/issues/26417
• 问题 #26528：使用 AddPooledDbContextFactory 时自动注册作用域的 DbContext https://github.com/dotnet/efcore/issues/26528