使用'DbContext'代替'ObjectContext'总是更好吗？

Question

我刚刚下载了EntityFramework.dll v4.3.我发现了一些用于比较的问题DbContext对ObjectContext.但其中大部分来自2010年或2011年初.

我想更多地了解这个主题.具体来说,有没有DbContext可以拿到书的书？我还想知道,截至今天,DbContext将它与其哥哥比较时有哪些局限性ObjectContext？

我意识到它DbContext更紧凑,因为它暴露更少的属性.这告诉我,我应该从中迁移ObjectContext.但是,如果我进行此迁移,我会放弃任何功能吗？例如,我读过DbContext没有STE(自跟踪实体)功能.这是否仍然适用,这是一个问题吗？

Answer 1

我想更多地了解这个主题.具体来说,有没有DbContext可以拿到书的书？

您的问题不是很好,因为单个Google查询会为您提供答案.有一本关于DbContext本身的优秀书籍 - 它没有包含有关Code First方法的任何内容,但我想这不是你问题的重点.

我发现了一些用于比较的问题DbContext对 ObjectContext.但其中大部分来自2010年或2011年初.

如果您只想用ObjectContext+ EDMX 替换+ DbContextEDMX,则比较仍然相同.DbContext是一个包装器ObjectContext,它的功能集没有成长,除了与Code First和Migrations相关的功能.

我意识到它DbContext更紧凑,因为它暴露更少的属性.这告诉我,我应该从中迁移 ObjectContext.

是的,它更紧凑,它简化了您必须对上下文执行的大多数常见任务.对于更复杂的任务,则仍可以将转换DbContext实例的ObjectContext通过实例IObjectContextAdapter.

但是,如果我进行此迁移,我会放弃任何功能吗？例如,我读过DbContext没有STE(自跟踪实体)功能.这是否仍然适用,这是一个问题吗？

STE是为ObjectContext我创建的,我不认为它被移植到了DbContext,但你可以尝试自己实现这个功能.

STE只是一个解决某些问题的模板.它似乎是一个很好的理论解决方案,但它并没有被开发人员社区很好地接受,因为该解决方案对于现实世界的场景并不是很好.这也是为什么开发其他更重要的功能而不是改进或移植模板的原因.