Entity Framework Core 延期及弃用的特性

由于破坏了向后兼容性，Entity Framework 的名声相当不光彩，但与 Entity Framework Core 的完全重写相比就相形见绌了。在本文中，InfoQ 将着眼于其中部分主要特性的变化及其影响。

延期及弃用的特性

首先，我们将看下那些 EF Core 1.0 没有支持并且也不在 EF Core 1.1 路线图上的 EF 6 特性。

延迟加载

一般来说，对于 Entity Framework 和 ORM 而言，延迟加载一直是一个备受争议的问题。EF 最初就不应该支持延迟加载，因为它很容易被误用，而且经常导致性能问题。

不过，在性能不是很重要的情况下，比如快速原型和实用工具，延迟加载还是非常有用的。因此，第二个主要版本 EF 4 增加了这一特性。（注意：为了与.NET Framework 的版本号保持一致，EF 跳过了版本 2 和 3。）

EF Core 没有提供延迟加载，这让一些人欢呼，也让其他人错愕。目前的建议是等待 EF Core 1.1，到时候，他们“可能会允许你推出自己的延迟加载。”根据 GitHub 及其他地方的各种讨论，还不清楚他们是否会直接支持它。

GROUP BY 转译

这一点令人难以理解。虽然 LINQ to SQL 在 10 年前就提供了支持，但 EF Core 的路线图上并没有 GROUP BY 支持。这意味着，如果你的查询中包含分组操作，EF Core 将在查询生成的时候忽略 GROUP BY 子句。

显而易见的结果是，这将极大地增加网络带宽要求，因为所有的底层数据都需要在聚合之前移到中间层。反序列化额外的数据也是有开销的，而且，在执行实际的分组操作时，C#的效率很有可能比数据库低。（数据库的优势是可以使用表的统计信息，如表的大小和分布，确定使用的最佳算法。）

存储过程

微软另一个让人吃惊的举措是不支持存储过程。虽然从技术上讲你仍然可以使用原始 SQL 访问它们，但那有许多限制。

• SQL 查询只能用于返回作为模型组成部分的实体类型。[该特性计划在.NET Core 1.1 中提供。]
• SQL 查询必须为实体类型的所有属性返回数据。
• 结果集中的列名必须与属性映射的列名相匹配。注意，这点和 EF6.x 不同。在 EF6.X 中，在使用原始 SQL 查询时，属性 / 列映射会被忽略，结果集列名必须和属性名匹配。
• SQL 查询不能包含关联数据。然而，在许多情况下，你可以使用 Include 操作符组合查询返回关联数据（参见“包含关联数据”）。

在某些情况下，你可以将原始 SQL 和 LINQ 表达式混合，比如向表 - 值函数查询添加 Where 或 OrderBy 调用。

空间数据类型

空间数据类型的情况比较有趣。当直接使用 ADO.NET 时，他们希望开发人员使用随 SQL Server 提供的、作为 COM 库（ Microsoft.SqlServer.Types ）封装器的空间类型。由于 COM 不能很好地与.NET 融合，尤其是在库的分发和注册要求方面，所以 Entity Framework 平行开发了自己的空间类型（ System.Data.Spatial ）集。这两种 API 都是以开放地理空间联盟（OGC）规范为基础，因此在基本功能方面非常相似。

目前为止，我们讨论的内容主要和SQL Server 相关。其他数据库会有其他的空间类型实现。因此，就可以理解，微软为什么正在花时间设法解决这个问题。

种子数据

虽然EF Core 支持数据库迁移，但不支持操作种子数据查找表。

简单命令拦截

命令拦截广泛应用于消除Entity Framework SQL 生成器的局限。例如，如果你希望在EF 中使用全文搜索，则需要实现IDbCommandInterceptor 接口，并重写ReaderExecuting/ScalarExecuting 方法。

这项技术相当复杂，而且严重依赖于确切地知道EF 会生成什么SQL。但是，没有这项技术，数据库的许多高级特性都无法使用了。

工具

之前的文章中已经提到过，最初随LINQ to SQL 和Entity Framework 提供的图形建模工具不会出现在EF Core 中。

而且，目前没有计划提供从数据库更新模型的能力。在可预见的未来，从数据库生成模型仍然会是一个一次性事件。

EF Core 1.1 的特性

EF Core 1.1 有望在明年 1 季度发布，除了 Bug 修复外，还包含以下特性。

改进转译

这个麻烦的标题缺少细节信息。它只是介绍说，“让更多的查询成功执行，在数据库（而不是内存）中进行更多的逻辑求值。”它还介绍说，EF 6 支持“简单”、“中等”和“复杂”查询。EF Core 的中等查询已经“稳定”，复杂查询支持还在开发中。

关于涵盖哪些场景的线索很少，所以开发人员需要格外仔细地检查生成的 SQL，并分析它们的数据库调用，以确保 EF 行为正常。

类似地，使用了导航属性的查询被认为仍处于开发中。

查询非模型类型

如上文所述，EF Core 1.1 有望能够物化不是模型组成部分的类型。

DbSet.Find

这是 EF 5 提供的一个方便的方法，用于通过主键加载记录，无需显式指定名称。它钩入上下文缓存，因此避免了不必要的数据库调用。它还可以找到已经附加到上下文但尚未保存到数据库（前提是你没有使用 identity/auto-number 列）的记录。

EntityEntry/ObjectStateEntry APIs

更多 EntityEntry 及 ObjectStateEntry 特性，如 Reload 、 GetModifiedProperties 、 GetDatabaseValues ，同样也在计划里。

显式加载

不要同“主动加载”混淆，显式加载允许将子集合加载到已经物化的实体中。可以将它看成是延迟加载外加一个额外的步骤。

连接恢复能力

这是一个很有前景的特性，它会自动重试因为连接问题导致失败的事务。“这在连接到 SQL Azure 时特别有用，在那种情况下，瞬时错误很常见。”

EF Core 下一个版本的特性

虽然预计不会在 EF Core 1.1 的时间框架内完成，但有些其他的特性正在准备中：

• 复杂 / 值类型是没有主键的类型，用于表示实体类型上的一组属性；
• 简单类型转换，如 string=>xml；
• 从已有的数据库进行模型逆向工程的 Visual Studio 向导。

查看英文原文： Delayed and Deprecated Features in Entity Framework Core