[关闭]
@lsmn 2016-08-03T22:10:32.000000Z 字数 2654 阅读 2541

Entity Framework Core延期及弃用的特性

微软 .NET EF


摘要

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

正文

由于破坏了向后兼容性,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特性,如ReloadGetModifiedPropertiesGetDatabaseValues,同样也在计划里。

显式加载

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

连接恢复能力

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

EF Core下一个版本的特性

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

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

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

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注