我想将基于FX 4.0和EF 4.0(Database First with ObjectContext)的大型项目升级到最新的6 / 6.1版EF。
我已经完成(成功)实际升级EDMX的所有步骤(添加T4模板,更改命名空间引用等等,这篇文章Upgrade EF 4 EDMX to EF 6之后),现在我的数据访问程序集正在编译中
为了快速完成工作,我使用ObjectContext T4模板执行升级,以期最大限度地减少所需的代码更改。我使用的模板是" EF 6.x EntityObject Generator模板"从Visual Studio Gallery开始,整个解决方案仍将基于.Net Framework 4.0。
我想知道使用ObjectContext而不是使用EF6的DBContext是否会减少或限制新EF 6的好处(我将继续使用Database First策略)。
答案 0 :(得分:2)
首先要考虑的是,Microsoft正在从EF7开始删除ObjectContext支持,因此如果您计划升级,则可以立即执行。
从正常的编码角度来看,DbContext或ObjectContext没有那么不同。大多数事情都是一样的。 DbContext具有更长的启动时间,因为它必须编译模型,但您也可以将预编译的视图加速。
DbContext很好地连接DataAnnotation Validations,它支持基于快照的更改检测,与ObjectContext相比,它实际上提高了性能。
如果您正在使用反射较重的东西,那么您将遇到问题,因为在运行时,对象是从运行时代理而不是您声明的类派生的。所以它需要一点点工作。我们有类似的东西,但后来我们在每个类上都设置了一个接口来实际检索正确的反射类型。
DbContext还将支持非数据库连接,例如Azure Table Storage或任何您自己的自定义存储。
大多数情况下,建议使用DbContext。因为它会留下来。 ObjectContext及其相应的EntityObject已被弃用。
答案 1 :(得分:1)
DbContext只是ObjectContext的一个(好的)包装器,可以很容易地使用Code First,它允许您轻松地使用POCO,并且通常使用它来构建数据层更方便。但实际上,使用DbContext的代码仍然使用下面的相同ObjectContext功能。
除了DbContext与ObjectContext相比有一些限制之外:例如,使用DbContext没有对StoredProcedures的开箱即用支持(除了来自CUD操作的存储过程),因此无论如何都必须回退到ObjectContext。
实体框架6带来了一些在代码使用方面不可见的好处,例如 - 改进的性能和错误修复。您将自动使用Context的任何一个。
修改强>
就个人而言,我全都在使用DbContext,因为它现在是一种“推荐”(事实上,唯一支持的)方式,但是如果你有一个非常大的数据库模型(有很多表,SP等) )和依赖它的代码库,迁移到DbContext将要求您对数据层进行重大更改,这些更改不会在短期内为您带来好处。但它肯定会改善您的系统设计,并使您能够长期获得未来的改进。
Entity Framework 7 announcement表示即将发生的重大变化(包括新平台和数据存储支持),这些变化在您的情况下可能会或可能不会有用。
这实际上意味着您应该仔细考虑现在和未来的目标。