【发布时间】:2010-09-07 04:44:57
【问题描述】:
DataContext 的最佳生命周期模型是什么?我是否应该在需要时创建一个新的(又名,函数级别),我应该在每个使用它的类中保留一个可用的(类级别),还是应该创建一个具有静态 DataContext 的静态类(应用程序域等级)?在这方面是否有任何公认的最佳做法?
【问题讨论】:
标签: linq-to-sql .net-3.5
DataContext 的最佳生命周期模型是什么?我是否应该在需要时创建一个新的(又名,函数级别),我应该在每个使用它的类中保留一个可用的(类级别),还是应该创建一个具有静态 DataContext 的静态类(应用程序域等级)?在这方面是否有任何公认的最佳做法?
【问题讨论】:
标签: linq-to-sql .net-3.5
如果您要存储稍后将要在.SubmitChanges()'d 进行的更改,您几乎需要在要执行的操作的整个生命周期内保持相同的数据上下文可用,否则您将丢失这些变化。
如果你只是查询东西,那么根据需要创建它们就可以了,但是如果以后你想.SubmitChanges(),你将不得不大量重构你的代码,所以你不妨采用有效的模式从一开始就在整个应用中保持datacontext 全局。
注意数据上下文是断开的。仅当查询数据被枚举时才建立连接(不是在您第一次运行查询时,它是一种“惰性”数据类型,因此仅在需要时提供数据),然后立即关闭。在.SubmitChanges() 上,打开连接以提交更改,然后立即关闭。所以不要认为保持datacontext 保持连接打开,它不会(您可以挂钩连接的StateChange 事件以自己确认这一点,这就是我确定的方式)。
Rick Strahl's Blog 上有一篇很棒的文章深入介绍了这个主题,远远超过我在这里提供的答案!!
【讨论】:
我认为 Jeff Atwood 在 Herding Code podcast 中谈到了这一点,当时他被问及完全相同的事情。在最后 15-20 分钟左右收听。
我认为在 SO 中,数据上下文是在 Controller 类中创建的。不确定这里的很多细节。但这就是它的样子。
【讨论】: