LINQ to SQL - 您的DataContext在哪里？

我在数据访问对象库中使用LINQ to SQL.该库用于Web(Web应用程序/ Web服务)和非Web(Windows服务)上下文.最初,我存储了DataContext当前,HttpContext因为它允许我管理一个相当小的工作单元(一个Web请求)并避免Web应用程序中的全局对象.显然,这在Windows服务中不起作用.

Rick Strahl有一篇关于管理DataContext生命的好文章:http://www.west-wind.com/weblog/posts/246222.aspx.不幸的是,我无法决定最好的方法.一个全球性DataContext的,他提到的原因不能正常工作,每个线程DataContext看起来很复杂,而且可能更麻烦比它的价值,并为每个对象实例似乎挑剔-你失去了一些优雅当您将DataContext用来创建一个DAO到DAO,因此可以update或delete稍后 - 更不用说,这种关系有一些不愉快的鸡肉和蛋白.

有没有人有个人经验表明一种方法比另一种更好？或者更好的是,有没有人有第四种或第五种方法,我没有看到？存储和管理您的最佳位置在哪里DataContext？

1> Bradley Grai..：

---

关于DataContext类的MSDN文档中的指南是我建议遵循的:

通常,DataContext实例设计为持续一个"工作单元",但是您的应用程序定义该术语.DataContext是轻量级的,创建起来并不昂贵.典型的LINQ to SQL应用程序在方法范围内创建DataContext实例,或者作为表示相关数据库操作的逻辑集的短期类的成员.

因为DataContext是IDisposable,我发现在一个方法中创建和使用DataContexta using语句最容易,因此可以正确处理它.

另请注意,"不保证任何实例成员都是线程安全的",因此DataContext在多个线程之间共享一个是不明智的.

---

据我了解,您仍然希望一个DataContext管理Entity的生命周期,以使SubmitChanges()正常工作而无需重新附加您的实体.正确？Fetch->编辑 - >提交.在这种情况下,您的DataContext位于方法范围之外,"使用"的价值较低.

---

@Andrei Rinea:虽然生成的类中的Dispose实现可能"相当无用",但基类(DataContext)中的实现却不是.

2> Robert Pauls..：

---

依赖注入.

我们希望保持我们的业务层对Web与非Web场景的无知.相反,业务逻辑层对象在其构造函数中采用DataContext引用,该引用明确地允许共享DataContext并且(隐式地)允许从查询结果共享实体对象,因为它们都来自相同的数据上下文.

DataContexts也实现了IDisposable,因此您确实需要管理它们的生命周期.我们所有的Web表单都有一个基类,其中一部分是datacontext属性(懒惰创建).这样,页面上的所有内容都可以共享它,这种情况最常见.上下文在页面的OnUnload()事件中手动处理.

---

您不应该混合来自不同数据上下文的linq实体,如果您使用linq实体,如果datacontext已经是Dispose(),那么通常会遇到麻烦.