EF Core 3 的 40 个中断性变更

为了修复 Entify Framework Core 中许多已发现的缺陷，微软在 EF Core 3 中引入了 40 个中断性变更。我们可以在微软文档中查看完整的中断性变更列表，本文仅列举几个主要的点。

客户端查询

为了突破 EF Core SQL 生成器的限制，默认只在客户端执行部分查询。这意味着对于部分不能转换成 SQL 的 LINQ 查询，需要从数据库加载数据表，并在内存中执行其余的操作。在 2.1 版本之前，Group By 都是在客户端执行的。

这种方式的缺点是，Where() 子句中的一个问题可能导致 EF Core 加载整张数据表。开发人员还发现，在无法生成相关子查询的情况下，它将执行成百上千个二级查询。

新的默认行为是 EF Core 仅允许在客户端执行最终的 Select() 操作。如果 EF Core 不能生成正确的 SQL，将引发异常。开发人员可以覆盖这个行为，但微软更希望开发者遇到这个问题时先尝试提交一个 bug 请求。

可以在“3.0查询指导原则大纲和决策点“中了解更多有关该变更的信息。

参数化及插值 SQL

正如我们在 2017 年报告的那样，EF Core的字符串插值特性引起了许多关注。使用该特性可以将内插字符串自动转换为参数化 SQL，但前提是这些字符串之前没有被存储在临时变量中。

v1 = context.Customers.FromSql($"SELECT * FROM Customers WHERE City = {city}");

var sql = $"SELECT * FROM Customers WHERE City = {city}";v2 = context.Customers.FromSql(sql);

在上面的例子中，v1 是正确参数化的，而 v2 则引入了一个 SQL 注入漏洞。

为了消除上述漏洞，将移除 FromSql 函数，并使用 FromSqlRawand 和 FromSqlInterpolated 替代。

临时键

EF Core 通常会创建临时主键来跟踪新实体。这些临时主键以负数的形式存储在键属性中（例如 CustomerKey 或 OrderId）。理论上，这些临时主键在生成时会被真正的键所替换，不过也存在几个例外情况，比如那些在用户界面上显示的假键甚至会被保存到数据库中。

EF Core 3 将把此类跟踪信息转移到实体的跟踪信息中，让键属性只持有数据。

级联删除时机

在调用诸如 context.Remove() 等方法时，级联删除将立即发生。在此之前，EF Core 在 SaveChanges 被调用之前不会计算哪些子项被删除，因此很难预测到底会发生什么。该变更主要影响那些用于记录将要修改/删除哪些数据项日志的代码。

可以通过将 CascadeDeleteTiming 和 DeleteOrphansTiming 选项设置成 CascadeTiming.OnSaveChanges 来还原以前的行为。

查询类型已过时

与之前版本的 Entity Framework 不同，EF Core 被设计成只能处理包含主键的数据表。这是有问题的，因为视图或存储过程的结果没有主键。所以 EF core 2.1 引入了查询类型的概念。

本质上，查询类型使用的是并行对象模型。开发人员使用 DbQuery 而不是 DbSet 来定义它们，使用 ModelBuilder.Query<>() 而不是 ModelBuilder.Entity<>() 来注册它们，并使用 DbContext.Query<>() 而不是 DbContext.Set<>() 来调用它们。

许多开发人员抱怨查询类型和实体类型之间存在不必要的混淆，因此查询类型被移除了。从 EF Core 3 开始，开发人员应该对所有数据源使用常规的 DbSet 模型。如果没有主键，开发人员在注册实体时只需使用 .HasNoKey() 来注解它们。

忽略属性的 Getter 和 Setter

在过去，除非要物化查询结果，否则 EF Core 将调用属性的 getter 或 setter 方法。在进行查询时，如果已知属性的支持字段，它将绕过属性，直接写入底层字段。

在这个变更之后，如果已知属性的支持字段，将始终使用底层支持字段。这样做的好处是可以防止意外触发业务逻辑。

缺点是诸如更新计算字段之类的业务逻辑也不会被触发。因此，我们可能需要修改 UsePropertyAccessMode 来获得我们想要的行为。

支持字端检测

在检测支持字段时，代码有时候会有歧义。在过去，EF Core 只能根据内部排名系统来猜测应该设置哪个字段。

在 EF Core 3 中，任何有歧义的地方都将抛出异常。不过，开发人员必须手动指出要使用模型生成器生成的哪个字段。

用 ValueTask 替换 Task

将 Task 作为对象被认为是.NET 的最大错误之一。虽然对于长时间运行的任务来说是可以接受的，但当创建了大量的短期任务时，它常常会造成过大的内存压力，所以新版本引入了基于结构的备选方案 ValueTask 。

为了支持这种新类型，更新了 FindAsync 和 NextValueAsync 等几个方法，让它们返回 ValueTask 而不是 Task 。这不会影响那些等待获取结果的代码，但如果要对任务执行其他操作，可能需要调用 AsTask() ，将其从 ValueTask 转换到 Task 。

简化 IEntityType 和 IProperty

删除了这两个接口中的五个属性，并用扩展方法进行替换。这样做的依据是如果接口表面越小就容易实现。

查看英文原文：40 Breaking Changes in EF Core 3