DataContext 的最佳使用模式

Question

最佳的生命周期模型是什么 DataContext？我是否应该在需要时创建一个新的（也称为函数级别），是否应该在每个使用它的类中保留一个可用的（类级别），或者我应该创建一个带有静态 DataContext 的静态类（应用程序域）等级）？这方面有没有经过深思熟虑的最佳实践？

Answer 1

如果您要存储要执行的更改，则您非常需要在要执行的操作的整个生命周期中保持相同的数据上下文可用 .SubmitChanges()稍后，否则您将丢失这些更改。

如果您只是查询内容，那么可以根据需要创建它们，但是如果稍后您想要 .SubmitChanges() 您将不得不大量重构代码，因此您不妨采用有效保留 datacontext 从一开始就在您的应用程序中发挥全局作用。

注意数据上下文是 断开连接. 。仅当查询数据时才建立连接 列举的 （不是当您第一次运行查询时，它是一种“惰性”数据类型，因此仅在需要时提供数据），然后立即关闭。在 .SubmitChanges() 打开连接以提交更改，然后立即关闭。所以不要认为保留 datacontext around 保持连接打开，但它没有（您可以挂接 StateChange 连接的事件要亲自确认这一点，这就是我所确定的）。

有一篇很棒的文章位于 里克·斯特拉尔的博客 其中深入涵盖了这个主题，远远超出了我在这里的回答！

Answer 2

我想杰夫·阿特伍德在 羊群法则播客, ，当他被问及完全相同的事情时。听最后 15-20 分钟左右。

我认为在 SO 中，数据上下文是在 Controller 类中创建的。这里不确定很多细节。但事实就是这样。