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修复外，还包含以下特性。

改进转译