LINQ to SQL - 您的DataContext在哪里?

时间:2008-10-12 23:05:37

标签: asp.net linq-to-sql

我在数据访问对象库中使用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的{​​{1}}附加到DAO,以便以后可以updatedelete - 更不用说,有一些不愉快的鸡肉 - 和 - 关于这段关系的问题。

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

4 个答案:

答案 0 :(得分:33)

MSDN documentation on the DataContext class的指南是我建议遵循的:

  

通常,DataContext实例是   旨在持续一个“单位   工作“但你的应用程序定义   那个词。 DataContext是   轻便且不贵   创建。典型的LINQ to SQL   应用程序创建DataContext   方法范围或实例   昙花一现的成员   代表一组相关的逻辑   数据库操作。

由于DataContextIDisposable,我发现在一个方法中在DataContext语句中创建和使用using最容易,因此可以正确处理它。

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

答案 1 :(得分:6)

依赖注入。

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

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


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

答案 2 :(得分:1)

我正在使用每线程上下文。设置很棘手,但它清理了需要与数据库通信的所有内容。

答案 3 :(得分:0)

我在Web场景中使用httpcontext,而在其他所有内容中使用线程上下文。我们构建了一个小框架,以便数据上下文完全从表示/业务层中抽象出来。