针对 Entity Framework Core 7.0 的计划

项目
01/31/2023

如规划过程中所述，我们已将利益干系人的意见收集到 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 版本;有关详细信息，请参阅 .NET Standard 的未来。 EF7 不会在.NET Framework上运行。

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

重大更改

随着 EF Core 和 .NET 平台的不断发展，EF7 将包含少量中断性变更。我们的目标是尽可能减少中断性变更。

主题

EF7 的巨额投资将主要包括以下主题：

被强烈要求的功能
NET 平台和生态系统
清除 EF6 的前进路径
性能

下面对每一个主题详细说明。可以在 EF Core 每两周更新中跟踪每个主题的高级状态。如有任何反馈或建议，请在 GitHub 问题 #26994 发表评论。

主题：被强烈要求的功能

与往常一样，计划过程中的主要输入内容来自对 GitHub 上功能的投票 (👍)。根据这些投票以及其他因素，我们计划为 EF7 开发以下要求很高的功能。

JSON 列

由问题 #4021 跟踪：将数据库中存储的 JSON 值映射到 EF 属性

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

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

批量更新

由问题 #795 跟踪：批量 (即基于集) CUD 操作 (，而无需将数据加载到内存)

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

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

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

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

生命周期挂钩

由问题 #626 跟踪：生命周期挂钩

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

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

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

由问题 #3170 跟踪：TPC 继承映射模式

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

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

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

将 CUD 操作映射到存储过程

由问题 #245 跟踪：将插入、更新和删除 (CUD 操作) 映射到存储过程

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

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

值对象

通过问题 #9906：使用 C# 结构或类作为值对象进行跟踪

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

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

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

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

由问题 #11597 跟踪：支持使用转换器生成更多类型的值

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

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

未映射类型的原始 SQL 查询

通过问题 #10753：支持原始 SQL 查询，而无需为结果定义实体类型进行跟踪

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

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

此处的工作还将介绍返回简单/标量类型（如、、 DateTimeint和 string）Guid的原始 SQL 查询。

数据库基架模板

由问题 #4038 跟踪：用于从现有数据库搭建实体类型和 DbContext 的代码模板

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

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

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

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

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

分布式事务

由 dotnet/runtime 中的问题 #715 跟踪：在 System.Transactions 中实现分布式/升级事务

价值主张：使用分布式事务的.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 工具进行跟踪

价值主张： dotnet ef 命令易于使用，可与新式平台和技术配合使用。

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

EF Core 和图形用户界面

由问题 #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，它都将继续作为连接 SQL Server 和 Azure SQL 的建议方法。引入新的 SQL Server 功能后，它将继续支持新功能。

Azure Cosmos DB 提供程序

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

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

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

请确保为所需的 Azure Cosmos DB 提供程序功能投票 (👍) ，以便我们可以评估投资位置，从而获得最大收益。

迁移体验

由问题 #22946：数据库迁移的改进进行跟踪

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

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

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

新式 .NET

随着 .NET 的不断发展，我们希望确保访问数据仍然是一种很好的体验。为此，我们计划在 EF7 时间范围内在三个方面取得进展。

修剪

由问题 #21894 跟踪：改进对 EF Core 应用的剪裁支持以减小应用程序大小

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

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

Evolve System.Linq.Expression

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

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

转换新的 LINQ 运算符

由问题 #25570 跟踪：支持新的 .NET LINQ 功能

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

最近已将新的 LINQ 运算符添加到 BCL，我们预计将来会添加更多运算符。问题 #25570 跟踪向 EF7 LINQ 提供程序添加对这些内容的支持。添加新的 LINQ 运算符时，此问题将更新。与所有现有 LINQ 运算符一样，仅当运算符对数据库进行合理且有用的转换时，我们才会添加支持。

ADO.NET 提供程序的开放遥测

由问题 #22336 进行跟踪：针对数据库跟踪的 DiagnosticSource/OpenTelemetry 进行标准化

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

开放遥测是 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 移植的更完整的指南

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

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

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

此外，我们计划在旧版 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 跟踪：改进更改跟踪和更新性能

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

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

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

TechEmpower 复合分数

由问题 26796 跟踪：提高 TechEmpower 复合分数的性能

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

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

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

其他功能

由 7.0 里程碑中标记的问题type-enhancement跟踪

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

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

建议

你对计划的反馈非常重要。请对 GitHub 问题 #26994 发表评论，并提供有关该计划的任何反馈或一般建议。指出问题重要性的最佳方式是在 GitHub 上为该问题投票 (👍)。然后，此数据将进入下一个版本的计划过程。