\

看新闻很累？看技术新闻更累？试试，每天上下班路上听新闻，有趣还有料！

\

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\u0026lt;object, string\u0026gt;参数的构造函数。集合（Collection）属性需要遵循如下模式编写：

\public ICollection Posts {\    get =\u0026gt; _lazyLoader.Load(this, ref _posts);\    set =\u0026gt; _posts = value;\}\

\在本例中，_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中表示为Geometry和Geography类型。两者间的不同之处在于，Geometry用于欧氏（平面）坐标系统，而Geography则用于更为复杂的椭圆坐标系统。

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

.NET Core中还规划了其它一些特性，可参见。

查看英文原文：