当前位置:新闻中心行业动态 → 正文

Entity Framework Core 2.0的突破性变更

责任编辑:editor004 作者:Jonathan Allen |来源:企业网D1Net  2017-08-30 11:38:45 本文摘自:INFOQ

在之前的文章里,我们看到了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

关键字:EFEventData

本文摘自:INFOQ

x Entity Framework Core 2.0的突破性变更 扫一扫
分享本文到朋友圈
当前位置:新闻中心行业动态 → 正文

Entity Framework Core 2.0的突破性变更

责任编辑:editor004 作者:Jonathan Allen |来源:企业网D1Net  2017-08-30 11:38:45 本文摘自:INFOQ

在之前的文章里,我们看到了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

关键字:EFEventData

本文摘自:INFOQ

电子周刊
回到顶部

关于我们联系我们版权声明隐私条款广告服务友情链接投稿中心招贤纳士

企业网版权所有 ©2010-2024 京ICP备09108050号-6 京公网安备 11010502049343号

^