Entity Framework Core延期及弃用的特性
2016-08-11 07:15
447 查看
由于破坏了向后兼容性,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向导。
原文地址:http://www.infoq.com/cn/news/2016/08/EF-Core-Roadmap
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注
延期及弃用的特性
首先,我们将看下那些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向导。
原文地址:http://www.infoq.com/cn/news/2016/08/EF-Core-Roadmap
.NET社区新闻,深度好文,微信中搜索dotNET跨平台或扫描二维码关注
相关文章推荐
- .Net Core 2.0生态(4):Entity Framework Core 2.0 特性介绍和使用指南
- Entity Framework Core 2.0 特性介绍和使用指南
- Entity Framework Core 2.0 新特性
- 【EF】Entity Framework Core 2.0 特性介绍和使用指南
- Entity Framework Core 2.0 新特性
- EntityFramework Core 1.1有哪些新特性呢?我们需要知道
- Entity Framework Core 2.0 新特性
- EntityFramework Core 1.1有哪些新特性呢?我们需要知道_0
- EntityFramework Core 1.1有哪些新特性呢?
- Entity Framework Core 2.0 新特性
- EntityFramework Core 1.1有哪些新特性呢?我们需要知道
- EntityFramework Core 1.1有哪些新特性呢?我们需要知道_0
- EntityFramework Core 1.1有哪些新特性呢?我们需要知道
- EntityFramework Core并发深挖详解,一纸长文,你准备好看完了吗?
- Entity Framework Core 使用HiLo生成主键
- Entity Framework Core Lolita
- Entity Framework Core 实现读写分离
- EntityFramework Core是否可以映射私有属性呢?了解一下。
- Entity Framework Core 入门(2)
- Entity Framework Core 数据库更新Migrations命令注意事情