针对 Entity Framework Core 6.0 的计划

  • 项目

重要

EF Core 6.0 现已发布。 本页面保留作为计划的历史记录。

如计划过程中所述，我们已将利益干系人输入的内容收集到针对 Entity Framework Core (EF Core) 6.0 版的计划中。 此计划会定期更新，以反映时间计划和范围的调整。

与以前的版本不同，此计划不会尝试覆盖 6.0 版的各项工作。 相反，它指出了我们打算在此版本中投入的方面和方式，而在我们一边使用该版本一边收集反馈和进行学习时，可灵活地调整范围或引入新工作。

重要

此计划不是承诺。 它是一个起点，会随着我们了解更多信息而发展。 其中可能会纳入当前未针对 6.0 计划的某些内容。 而当前已针对 6.0 计划的某些内容可能会被淘汰。

常规信息

版本号和发布日期

EF Core 6.0 是 EF Core 5.0 之后的下一版本，目前计划在 2021 年 11 月与 .NET 6 同时发布。

受支持的平台

EF Core 6.0 需要 .NET 6。 EF Core 6.0 不面向任何 .NET Standard 版本；有关详细信息，请参阅 .NET Standard 的未来。

EF Core 6.0 不会在 .NET Framework 上运行。

EF Core 6.0 将作为长期支持 (LTS) 版本与 .NET 6 保持一致。

中断性变更

我们将继续改进 EF Core 和 .NET 平台，因此 EF Core 6.0 将包含少量中断性变更。 我们的目标是允许大多数应用程序进行更新而不会中断。

主题

以下方面将构成 EF Core 6.0 中多数投资的基础。

被强烈要求的功能

与往常一样，计划过程中的主要输入内容来自对 GitHub 上功能的投票 (👍)。 对于 EF Core 6.0，我们计划处理以下被强烈要求的功能：

SQL Server 临时表

通过 #4693 进行跟踪

状态： 完成

T 恤大小：大

临时表支持查询在任何时间点存储在表中的数据，而不是像普通表那样仅限存储的最新数据。 EF Core 6.0 将允许通过迁移来创建临时表，并允许通过 LINQ 查询访问数据。

这项工作最初作用的范围如问题所述。 我们可能会根据发布期间的反馈引入其他支持。

JSON 列

通过 #4021 进行跟踪

状态：剪切

T 恤大小：中

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

ColumnAttribute.Order

通过 #10059 进行跟踪

状态：正在进行

T 恤大小：小

此功能将允许在使用迁移或 EnsureCreated 创建表时对列进行任意排序。 请注意，更改现有表中列的顺序需要重新生成表，而我们并不计划在任何 EF Core 版本中支持这项功能。

性能

虽然 EF Core 的速度通常比 EF6 更快，但某些方面仍存在大幅提升性能的空间。 我们计划在 EF Core 6.0 中处理其中的几个方面，同时改进我们的性能基础结构和测试。

本主题将涉及大量迭代调查，它将告知我们要将资源集中到哪些方面。 我们计划从以下方面开始：

性能基础结构和新测试

状态：已限定范围/完成

T 恤大小：中

EF Core 代码库已包含一组性能基准，它们每日都会执行。 对于 6.0 版，我们计划改进这些测试的基础结构并添加新测试。 我们还将分析主线性能方案，并修复发现的任何可轻松解决的问题。

更新：我们改进了测试基础结构并添加了新测试，以支持为 EF Core 6 所做的工作。 这一方面的其他改进已纳入 EF Core 6.0 版本的范围。

已编译的模型

通过 #1906 进行跟踪

状态： 完成

T 恤大小：加大

已编译的模型将允许生成 EF 模型的编译形式。 这将提供更好的启动性能，通常还在访问模型时提供更好的性能。

TechEmpower Fortunes

通过 #23611 进行跟踪

状态： 完成

T 恤大小：加大

几年来，我们一直在 .NET 上针对 PostgreSQL 数据库运行行业标准的 TechEmpower 基准。 Fortunes 基准 与 EF 方案尤为相关。 我们有此基准的多个变体，包括：

  • 直接使用 ADO.NET 的实现。 这是此处列出的三个实现中最快的一个。
  • 使用 Dapper 的实现。 与直接使用 ADO.NET 相比，该实现更慢，但仍然很快。
  • 使用 EF Core 的实现。 这是当前三个实现中最慢的一个。

EF Core 6.0 的目标是使 EF Core 的性能与 TechEmpower Fortunes 基准上的 Dapper 不相上下。 （这是一项重大挑战，但我们将尽最大努力尽量实现。）

链接器/AOT

通过 #10963 进行跟踪

状态：已限定范围/完成

T 恤大小：中

EF Core 执行大量的运行时代码生成。 对于依赖链接器树握手（如 Xamarin 和 Blazor）的应用模型以及不允许动态编译的平台（如 iOS）来说，这非常困难。 作为 EF Core 6.0 的一部分，我们将继续调查该方面，并尽可能进行有针对性的改进。 不过，我们并不期望在 6.0 版期限内完全消除差距。

迁移和部署

根据对 EF Core 5.0 的调查，我们计划引入对管理迁移和部署数据库的改进支持。 这包括两个主要方面：

迁移捆绑包

通过 #19693 进行跟踪

状态： 完成

T 恤大小：中

迁移捆绑包是一种独立的可执行文件，用于将迁移应用到生产数据库。 此行为将与 dotnet ef database update 匹配，但由于所需的所有内容都包含在单个可执行文件中，因此它会使 SSH/Docker/PowerShell 部署更容易。

管理迁移

通过 #22945 进行跟踪

状态：剪切

T 恤大小：大

为应用程序创建的迁移数可能会增加，从而成为负担。 此外，即使不需要，这些迁移也经常与应用程序一起部署。 在 EF Core 6.0 中，我们计划通过更好的工具和项目/程序集管理来改进这一点。 我们计划解决的两个具体问题是将多个迁移压缩为一个迁移和重新生成干净的模型快照。

更新：由于资源限制，这一方面的大部分工作已在 6.0 中移除。

改进现有功能并修复 bug

分配给 6.0.0 里程碑的任何问题或 bug 目前都计划在此版本中解决。 这包括许多小型改进和 bug 修复。

EF6 查询奇偶校验

通过使用“ef6-parity”标记的问题和 6.0 里程碑中的问题进行跟踪

状态：已限定范围/完成

T 恤大小：大

EF Core 5.0 支持 EF6 支持的大多数查询模式，也支持 EF6 不支持的模式。 对于 EF Core 6.0，我们计划缩小差距，使受支持的 EF Core 查询成为受支持的 EF6 查询的真正超集。 这将由对差异的调查来推动，但已包含 GroupBy 问题（例如转换后接 FirstOrDefault 的 GroupBy），以及针对基元和未映射类型的原始 SQL 查询。

更新：由于资源限制和优先级调整，针对原始类型和未映射类型的原始 SQL 查询已从 6.0 中删除。

值对象

通过 #9906 进行跟踪

状态：剪切

T 恤大小：中

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

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

Azure Cosmos DB 数据库提供程序

通过使用“area-cosmos”标记的问题和 6.0 里程碑中的问题进行跟踪

状态：展开/完成

T 恤大小：大

我们正在积极收集有关对 EF Core 6.0 中的 Azure Cosmos DB 提供程序进行哪些改进的反馈。 我们会在了解更多信息后更新此文档。 现在，请务必为你需要的 Azure Cosmos DB 功能投票 (👍)。

更新：我们一直在围绕 Azure Cosmos DB 提供程序进行广泛的客户开发。 这使得 EF Core 6.0 引入了以下增强功能：

更新：以下问题已从 6.0 版本中消除：

向应用程序公开模型构建约定

通过 #214 进行跟踪

状态：剪切

T 恤大小：中

EF Core 使用一组约定来从 .NET 类型构建模型。 这些约定当前由数据库提供程序控制。 在 EF Core 6.0 中，我们打算允许应用程序与这些约定挂钩并更改这些约定。

零 bug 平衡 (ZBB)

通过 6.0 里程碑中使用 type-bug 标记的问题进行跟踪

状态：正在进行中/已限定范围

T 恤大小：大

我们计划在 EF Core 6.0 版期限内修复所有待解决的 bug。 需谨记以下几点：

  • 这特别适用于标记了 type-bug 的问题。
  • 存在一些例外，例如当需要设计更改或新功能才能正确修复 bug 时。 这些问题将使用 blocked 标签进行标记。
  • 当我们即将发布 GA/RTM 版本时，我们会在需要时根据风险来修复 bug。

其他功能

通过 6.0 里程碑中使用 type-enhancement 标记的问题进行跟踪

状态： 完成

T 恤大小：大

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

更新：以下问题已从 6.0 版本中消除：

.NET 集成

EF Core 团队还致力于几种相关但独立的技术。 具体而言，我们计划在以下方面开展工作：

对 System.Data 进行改进

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

状态：已限定范围/完成

T 恤大小：大

这项工作包括：

  • 实现新的批处理 API。
  • 继续与其他 .NET 团队和社区合作，来了解和发展 ADO.NET。

更新：以下问题已从 6.0 版本中消除：

对 Microsoft.Data.Sqlite 进行改进

通过 6.0 里程碑中使用 type-enhancement 和 area-adonet-sqlite 标记的问题进行跟踪

状态：已限定范围/完成

T 恤大小：中

为 Microsoft.Data.Sqlite 规划了几项细微改进（包括连接池和预定义语句）来提高性能。

更新：准备好的语句已从 6.0 版本中删除。

可为空引用类型

通过 #14150 进行跟踪

状态： 完成

T 恤大小：大

我们将对 EF Core 代码进行批注来使用可为空引用类型。

试验和调查

EF 团队计划在 EF Core 6.0 版期限内投入时间，在两个方面进行试验和调查。 这是一个学习过程，因此没有针对 6.0 版本计划具体的可交付成果。

SqlServer.Core

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

状态：正在进行

T 恤大小：进行中

Microsoft.Data.SqlClient 是 SQL Server 的功能齐全的 ADO.NET 数据库提供程序。 它在 .NET Core 和 .NET Framework 上都支持多种 SQL Server 功能。 不过，它也是一个较大的旧代码库，其行为之间存在很多复杂的交互。 这使得很难调查使用较新的 .NET Core 功能可能带来的潜在好处。 因此，我们将与社区协作开展一项试验，以确定 .NET 的高性能 SQL Server 驱动程序有何潜力。

重要

对 Microsoft.Data.SqlClient 的投资不会改变。 无论是否使用 EF Core，它都将继续作为连接 SQL Server 和 SQL Azure 的建议方法。 引入新的 SQL Server 功能后，它将继续支持新功能。

GraphQL

状态：正在进行

T 恤大小：进行中

在过去几年里，GraphQL 在各种平台上获得了广泛的关注。 我们计划对该方面进行调查，并找到改进 .NET 体验的方法。 这涉及到与社区协作来了解和支持现有生态系统。 它还可能涉及来自 Microsoft 的特定投入，可能是对现有工作进行贡献，也可能是在 Microsoft 堆栈中开发补充部分。

DataVerse（以前称为 Common Data Service）

状态：正在进行

T 恤大小：进行中

DataVerse 是一种基于列的数据存储，旨在快速开发商业应用程序。 它会自动处理复杂的数据类型，如二进制对象 (BLOB)，并具有内置的实体和关系，如组织和联系人。 虽然存在 SDK，但具有 EF Core 提供程序可能有利于开发人员，他们可由此使用高级 LINQ 查询、利用工作单元，并具有一致的数据访问 API。 团队将考虑使用不同的方法来改进 .NET 开发人员连接 DataVerse 的体验。

Below-the-cut-line

通过使用 consider-for-current-release 标记的问题进行跟踪

当前未针对 6.0 版本计划这些 bug 修复和增强功能，但我们将根据整个版本使用过程中的反馈以及在上述工作中所取得的进展来进行研究。 这些问题可能会引入到 EF Core 6.0，并将自动成为下一个版本的候选项。

此外，我们始终会在计划时考虑投票最多的问题。 从版本中去除其中任何问题总是很痛苦的，但是我们确实需要针对所拥有的资源制定切合实际的计划。 请务必对你需要的功能投票 (👍)。

建议

你对计划的反馈非常重要。 指出问题重要性的最佳方式是在 GitHub 上为该问题投票 (👍)。 然后，此数据将进入下一个版本的计划过程。