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

Question

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

我想更多地了解这个主题。具体来说，DbContext上是否有任何书籍可以帮助我？我还想知道，截至今天，DbContext与其哥哥ObjectContext进行比较时有哪些限制？

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

Answer 1

  

我想更多地了解这个主题。具体来说，有没有   DbContext上的书我可以动手了吗？

您的问题并非开始，因为单个Google查询会为您提供答案。有一个excellent book about DbContext本身 - 它不包含任何有关Code First方法的内容，但我想这不是你问题的重点。

  

我发现了一些比较DbContext与   ObjectContext。但其中大部分来自2010年或2011年初。

如果您只想将ObjectContext + EDMX替换为DbContext + EDMX，则比较仍然相同。 DbContext是ObjectContext的包装器，除了与Code First和Migrations相关的功能外，其功能集没有增长。

  

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

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

  

但是，如果我进行此迁移，我会放弃任何功能吗？对于   例如，我读过DbContext没有STE（自我跟踪）   实体）能力。这是否仍然适用，这是一个问题吗？

STE是为ObjectContext创建的，我不认为它被移植到DbContext，但您可以尝试自己实现此功能。

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