写点什么

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

2018 年 3 月 08 日

看新闻很累?看技术新闻更累?试试下载 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)属性需要遵循如下模式编写:

复制代码
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

2018 年 3 月 08 日 18:001688
用户头像

发布了 376 篇内容, 共 93.8 次阅读, 收获喜欢 214 次。

关注

评论

发布
暂无评论
发现更多内容

快进收藏吃灰!字节跳动大佬用最通俗方法讲明白了红黑树算法

小Q

Java 学习 架构 面试 算法

Springboot过滤器和拦截器详解及使用场景

996小迁

Java 编程 架构 面试 springboot

Scrum指南这么改,我看要完蛋!

华为云开发者社区

Scrum 敏捷 改版

公众号高频被调整,它不是企业生产文章的机器

Linkflow

客户数据平台 CDP 私域流量

强化学习入门必看之强化学习导识

Alocasia

人工智能 学习

深入浅出 Go - sync.Map 源码分析

哈希说

golang

架构师训练营第九周作业

我是谁

极客大学架构师训练营

深入理解h2和r2dbc-h2

程序那些事

响应式编程 R2DBC 程序那些事 响应式架构 r2dbc-h2

微信官方将打击恶意营销号:自媒体不可过度消费粉丝

石头IT视角

面试官问:如何排除GC引起的CPU飙高?我脱口而出5个步骤

田维常

cpu飙满

架构师训练营第九周作业

_

极客大学架构师训练营 第九周作业

DataPipeline CTO 陈肃:构建批流一体数据融合平台的一致性语义保证

DataPipeline

数据融合

6. 自定义容器类型元素验证,类级别验证(多字段联合验证)

YourBatman

Hibernate-Validator Bean Validation 多字段联合验证

数字货币交易所开发有哪些模式?区块链交易平台

13530558032

深入浅出 Go - sync.Once 源码分析

哈希说

golang

区块链社交即时通许系统开发,区块链社交app开发价格

13530558032

11月阿里Spring全家桶+MQ微服务架构笔记:源码+实战

小Q

Java 学习 程序员 面试 微服务

合约跟单源码案例,合约跟单模式开发

13530558032

DataPipeline CPO 陈雷:实时数据融合之法,稳定高容错

DataPipeline

数据融合

阿里达摩院副院长亲自所写Java架构29大核心知识体系+大厂面试真题+微服务

Java架构追梦

Java 学习 阿里巴巴 架构 面试

Istio 1.8 发布——用户至上的选择

Jimmy Song

开源 云原生 Service Mesh istio

区块链数字货币钱包开发,去中心化钱包搭建app

WX13823153201

《JAVA多线程设计模式》.pdf

田维常

多线程

DataPipeline CPO 陈雷:实时数据融合之道,博观约取,价值驱动

DataPipeline

数据融合

接口测试学习之json

测试人生路

json 接口测试

UNISKIN COO Kevin|营销数字化:数据沉淀和数据系统化运营一定要趁早!

Linkflow

营销数字化 客户数据平台 CDP

区块链数字钱包系统开发方案,区块链钱包APP源码

13530558032

万字图文 | 聊一聊 ReentrantLock 和 AQS 那点事(看完不会你找我)

源码兴趣圈

架构 AQS ReentrantLock JUC CLH

DataPipeline CPO 陈雷:实时数据融合之法,便捷可管理

DataPipeline

数据融合

媲美物理机,裸金属云主机如何轻松应对11.11大促

京东科技开发者

云计算 服务器 云主机 裸金属容器

前嗅教你大数据——史上最全代理IP服务商对比

前嗅大数据

大数据 数据采集 动态代理 静态代理 代理IP

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

2021年全国大学生计算机系统能力大赛操作系统设计赛 技术报告会

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