写点什么

Entity Framework Core 2.0 的突破性变更

2017 年 8 月 29 日

在之前的文章里,我们看到了 EF Core 2.0 的新特性槽点。今天,我们来看一看EF Core 的突破性变更。

不支持EF Core 1.x 数据库驱动器

EF 通过数据库驱动器为 SQL Server、MySQL 等数据库生成 SQL。EF 没有通用的 OleDB 或 ODBC 驱动器,所以只能使用专门为它创建的数据库驱动器。

为了简化数据库驱动器的开发,EF Core 更改了驱动器 API,不再提供向后兼容的能力。这意味着 EF Core 1.0 和 1.1 的驱动器不再受 EF Core 2.0 的支持,如果要继续使用它们,必须基于 EF Core 2.0 的 API 对它们进行重写。

根据微软所述,“ SQL Compact PostgreSQL MySQL 的第三方开源数据库驱动器正在升级到 2.0”。如果使用了其他数据库,需要自行联系驱动器开发者。

IDbContextFactory 被重命名为 IDesignTimeDBContextFactory

IDbContextFactory 类不应该被作为 DbContext 工厂类来使用,虽然它的名字看起来有这个意味。实际上,这个类本应被用在设计工具里,设计工具在生成数据库迁移脚本时需要用到 DbContext 对象。

为了避免混淆,IDbContextFactory 被标记为“过时”的,设计工具可以改为调用 IDesignTimeDBContextFactory。

与此相关的另一个变更是停止对 DbContextFactoryOptions 的支持,这个类不适用于设计时上下文的生成。

日志和诊断事件的变更

EF Core 的日志和诊断事件变更包括:

  • 发送给 ILogger 的消息事件 ID 发生了变化。事件 ID 在整个 EF Core 里是唯一的,而且消息遵循了 MVC 所使用的结构化日志标准模式。
  • 日志类别也发生了变化。现在可以通过 DbLoggerCategory 访问到各种日志类别。
  • DiagnosticSource 使用了与相应 ILogger 消息相同的事件 ID。事件内容均为派生自 EventData 的标准类型。

虽说上面列出的都算得上是突破性的变更,但微软希望它们不会对现有的应用程序造成太大的影响。

内存数据库必须指定名字

在进行性能测试时,创建内存数据库是非常重要的一个辅助手段。虽然这并不能反映应用程序在生产环境的真实行为,但在诊断业务逻辑时还是很有用的。

EF Core 之前可以支持一个全局的匿名内存数据库,但现在要求开发人员必须为创建的每一个内存数据库命名。不过,同一个内存数据库仍然可以被多个上下文实例所共享。

只读 API 的变更

EF Core 停止支持由 IProperty 接口暴露出来的 IsReadOnlyBeforeSave、IsReadOnlyAfterSave 和 IsStoreGeneratedAlways。它们被 IProperty 的 BeforeSaveBehavior 和 AfterSaveBehavior 所取代。文档里写道:

被标记为 ValueGenerated.OnAddOrUpdate 的属性默认会忽略当前设定的值。也就是说,不管被追踪实体的属性是否发生了变化,比如被设定初始值或者被修改为其他值,它们都只使用 store-generated 的值。要想让改变生效,可以通过设置 BeforeSaveBehavior 或 AfterSaveBehavior 来实现。

因为添加了新的字段,所以对于 IProperty 来说,这也算是一个突破性的变更。

ClientSetNull 成为默认的删除行为

之前,EF Core 有三种可能的级联删除行为

  • Cascade:依赖的实体也一并被删除。这种级联行为只对被上下文跟踪到的实体有效。数据库里也需要设置相应的级联,确保没有被上下文跟踪到的数据也具备同样的行为。如果你通过 EF 来创建数据库,那么 EF 会为你设置好数据库的级联。
  • Restrict:删除操作不会作用在依赖实体上,依赖实体保持不变。
  • SetNull:依赖实体的外键被设为 null。这种级联行为只对被上下文跟踪到的实体有效。数据库里也需要设置相应的级联,确保没有被上下文跟踪到的数据也具备同样的行为。如果你通过 EF 来创建数据库,那么 EF 会为你设置好数据库的级联。

EF Core 2.0 新增了一种默认行为,叫作 ClientSetNull。

EF Core 2.0 引入了一种叫作 ClientSetNull 的默认行为。它具有 SetNull 的语义,兼有 Restrict 的行为。从我们的经验来看,对于被跟踪的实体和数据库来说,它是最被期待也是最有用的一种行为。

在为被跟踪的实体设置级联关系时,DeleteBehavior.Restrict 已经成为历史。

设计时工具包的合并

Microsoft.EntityFrameworkCore.Relational.Design 包被弃用,原先的内容被合并到 Microsoft.EntityFrameworkCore.Relational 和 Microsoft.EntityFrameworkCore.Design 当中。这样做的好处是现在可以少引入一个包。

在后续的文章中,我们将会看到 EF Core 的路线图。

查看英文原文: Breaking Changes in EF Core 2.0

2017 年 8 月 29 日 19:001867
用户头像

发布了 321 篇内容, 共 108.1 次阅读, 收获喜欢 101 次。

关注

评论

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

架构师训练营 week2 课后练习

花果山

极客大学架构师训练营

第 6 周 作业

Pyr0man1ac

Week2作业

幸福小子

1.请简述 CAP 原理。

张荣召

week6

张兵

极客大学架构师训练营

架构师训练营第六周命题作业

一马行千里

极客大学架构师训练营 命题作业

第 5 周 作业

Pyr0man1ac

架构师系列之3 接口分离原则

桃花原记

第2周作业

Steven

极客大学架构师训练营

架构师训练营 - 第六周作业

一个节点

极客大学架构师训练营

技术选型(2)课后作业

ABS

架构师训练营week06

FG佳

架构师一期

架构师训练营 - 第六周 - 作业一

行者

第六周 技术选型 作业一

应鹏

极客大学架构师训练营

架构师训练营第二周学习总结

张小胖

极客大学架构师训练营

架构师1期week05

FG佳

第二周

宇文青

第六周总结

_

极客大学架构师训练营 第六周总结

依赖倒置原则

落朽

架构第六周作业

Geek_Gu

极客大学架构师训练营

架构师训练营第 2 期 第二周总结

月下独酌

week2学习总结

幸福小子

依赖倒置原则、接口隔离原则优化类的设计

Calvin

极客大学架构师训练营

链表实现插入排序、机器学习Top 10 算法、图数据库实战Neptune、John 易筋 ARTS 打卡 Week 24

John(易筋)

学习 ARTS 打卡计划 链表实现插入排序 图数据库实战 Neptune

第六周 技术选型 学习总结

应鹏

学习 极客大学架构师训练营

第 5 周 这东西也有标准化答案???

Pyr0man1ac

框架设计原则

笨笨程序猿

架构设计 极客大学架构师训练营 接口隔离

极客时间 - 架构师一期 - 第六周作业

_

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

第二周作业总结

hunk

极客大学架构师训练营

【架构师训练营第 1 期 06 周】 学习总结

Bear在挨踢

极客大学架构师训练营

第六周作业

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

Entity Framework Core 2.0的突破性变更-InfoQ