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() 来注解它们。