针对 Entity Framework Core 7.0 的计划

项目
10/05/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，我们计划实现批量更新和删除（但不插入）。请注意，批量更新与批处理更新不同。 EF Core 在通过SaveChanges向数据库发送更新时，已将对许多跟踪实体的更改合并成批。

生命周期挂钩

通过问题 #626：生命周期挂钩进行跟踪

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

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

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

通过问题 #3170：TPC 继承映射模式进行跟踪

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

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

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

将 CUD 操作都映射到存储过程

通过问题 #245：将插入、更新和删除（CUD 操作）映射到存储过程进行跟踪

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

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

值对象

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

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

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

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

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

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

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

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

未映射类型的原始 SQL 查询

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

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

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

此处的工作还将涵盖返回简单/标量类型的原始 SQL 查询，例如Guid、DateTime、int和string。

数据库基架模板

通过问题 #4038：用于从现有数据库为实体类型和 DbContext 搭建基架的代码模板进行跟踪

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

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

主题：NET 平台和生态系统

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

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

分布式事务

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

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

.NET Framework 中的System.Transactions库包含本机代码，它利用 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) 编译更高效。

改进 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 清除路径转发

通过文档问题 #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 上为该问题投票 (👍)。然后，此数据将进入下一个版本的计划过程。