EF Core 2.1路线图:视图、GROUP BY和惰性加载

2018阿里云全部产品优惠券(好东东,强烈推荐)
领取地址https://promotion.aliyun.com/ntms/act/ambassador/sharetouser.html?userCode=gh9qh5ki&utm_source=gh9qh5ki

推荐:[置顶] 接口性能测试方案 白皮书 V1.0

[一、 性能测试术语解释 1. 响应时间 响应时间即从应用系统发出请求开始,到客户端接收到最后一个字节数据为止所消耗的时间。响应时间按软件的特点再可以细分,如对于一

看新闻很累?看技术新闻更累?试试 下载InfoQ手机客户端 ,每天上下班路上听新闻,有趣还有料!

Entity Framework Core一直追随着初始Entity Framework的发展,并不断推陈出新。它首先推出的是对视图的支持,这听起来有些耸人听闻。在即将推出的EF Core 2.1之前,EF Core并未对数据库视图提供官方的支持,也不支持缺少主键的数据库表,尽管后一种情况十分罕见。

EF Core 2.0提供了一种变通方案。开发人员可以使用ROW_NUMBER创建一个代理主键,和声明数据库表一样去声明视图。此后,就可以将视图视为数据库表,配置数据库的上下文。

但是开发人员不能修改视图返回ROW_NUMBER,因为列的组合并非是唯一的。开发人员可以使用 Key 属性随机标记列,然后使用 AsNoTracking 回避EF的缓存逻辑,以免遗弃了一些“重复”的行。

在EF Core 2.1中,支持采用另一种做法。开发人员可以设置视图的“查询类型”,或将内联(inline)SQL设置为“只读”的。这样,不再需要数据库表必须具有主键。

对GROUP BY的支持

在EF Core中,另一个出乎意料的限制是不支持生成SQL中的GROUP BY操作。当前,整个数据集在传送到客户端后,EF Core需在内存中执行分组操作。和在数据库中执行分组操作相比,EF Core的操作将会导致明显更高的网络、内存和CPU占用。

随着EF Core 2.1的发布,分组操作的执行变通为在视图中或内联SQL中进行。之后,开发人员可以使用上述解决方法,即将视图看成是数据库表。

惰性加载(Lazy Loading)

我们知道,EF Core中讨论最为激烈的特性就是惰性加载。虽然有一些开发人员乐此不疲,但也另有一些人将其视洪水猛兽,认为其中充斥着大量可导致低性能或运行时意外失败的陷阱。EF Core 2.1中添加了惰性加载特性,但是有别于我们先前在最初的Entity Framework中所看到的。

要启用惰性加载,对象中必须具有一个接受 Action<object, string> 参数的构造函数。集合(Collection)属性需要遵循如下模式编写:

推荐:告别码农,成为真正的程序员

[ 本文是我借助 Google 从网上拼凑的文章,可能条理不是很清晰,希望对广大程序员们有些帮助。 一、成长的寓言:做一棵永远成长的苹果树 一棵苹果树,终于结果了。 第

public ICollection
<post>
  Posts {
    get => _lazyLoader.Load(this, ref _posts);
    set => _posts = value;
}

</post>

在本例中, _lazyLoader 就是上面提及的由构造函数提供的 Action 对象。 Load 是一个回调EF Core的扩展函数。

和初始的EF版本一样,在未来的EF Core版本中,有望无需编写此类“八股代码”(boilerplate code)就可实现惰性加载。

事务

EF Core一直支持事务,但仅局限于支持数据库事务。在下一版本中,开发人员将可以使用 System.Transactions 命名空间提供的 TransactionScope 等功能。该特性也称为“氛围事务”(ambient transaction),它支持多个资源间协调事务,包括数据库、消息队列、Web服务和文件系统等。例如,开发人员可在对事务NTFS硬盘的写操作失败的情况下,自动回滚数据库更改。

值转换

对值转换的支持,是ORM中一个常常被低估的特性。简而言之,该特性处理诸如将枚举类型按其底层的整数值或字符串表示存储等问题。但是如果需要ORM支持多种数据库引擎,事情就变得十分复杂。

假定数据模型中存在无符号整数。部分数据库原生地支持无符号整数,因此不存在问题。但是诸如SQL Server等数据库只支持有符号整数。如果需要数据模型同时支持两者,那么ORM具备处理转换能力就尤为重要。

在EF Core 2.1路线图中,更进一步支持插入开发人员定制的转换逻辑。该特性将支持对属性值的透明加/解密等特性。

空间数据类型

新路线图收到的首个反馈,就是再次呼吁支持空间数据类型(Spatial Data Type)。空间数据在SQL Server中表示为 GeometryGeography 类型。两者间的不同之处在于, Geometry 用于欧氏(平面)坐标系统,而 Geography 则用于更为复杂的椭圆坐标系统。

EF Core 2.1对空间数据提供了部分支持。首先,开发需要运行在.NET Framework上,因为.NET Core中并未提供处理空间数据所需的库。其次,开发人员需要使用视图或内联SQL,将几何和地理数据转换为 WKB(熟知二进制,well-known binary)WKT(熟知文本,well-known text) 。WKB/WKT是表示此类空间数据的工业标准。最后,开发人员可以着手编写值转换器(方法如上所述),实现适当的.NET对象与WKB/WKT间的相互转换。

.NET Core中还规划了其它一些特性,可参见 EF 2.1路线图的通讯稿

查看英文原文: EF Core 2.1 Roadmap: Views, Group By, and Lazy Loading

推荐:[置顶] 程序员面试、算法研究、编程艺术、红黑树、机器学习5大系列集锦,海量数据处理面试题集锦与Bit-map详解,教你如何迅速秒杀掉:99%的海量数据处理面试题,九月腾讯,创新工场,淘宝等公司最新面试三十题(第171-2

[程序员面试、算法研究、编程艺术、红黑树、数据挖掘5大经典原创系列集锦与总结作者:July--结构之法算法之道blog之博主。时间:2010年10月-2012年11月。出处:http://blog

在线网页数据采集器

相关推荐