我在数据访问对象库中使用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似乎很复杂，可能比它的价值更麻烦，每个对象的实例似乎很挑剔——当你把用于创建DAO的DataContext附加到DAO上，这样它以后就可以update或delete时，你就失去了一些优雅——更不用说，这段关系有点令人不快的鸡气和蛋气。
有没有人的个人经验表明一种方法比另一种更好？或者更好的是，有人有我没有看到的第四种或第五种方法吗？哪里是存放和管理DataContext的最佳场所？
MSDN文档中关于DataContext类的指导原则是我建议的：
通常，DataContext实例是设计为持续一个"单位工作"这个术语。DataContext是重量轻且不昂贵创造一个典型的LINQ to SQL应用程序创建DataContext方法范围或作为属于短命类的成员表示相关的逻辑集数据库操作。
因为DataContext是IDisposable，所以我发现在一个方法中在using语句中创建和使用DataContext最简单，因此可以正确地处理它。
还要注意，"任何实例成员都不能保证是线程安全的"，因此在多个线程之间共享一个DataContext是不明智的。
依赖注入。
我们更喜欢让我们的业务层对网络和非网络场景一无所知。相反，业务逻辑层对象在其构造函数中采用DataContext引用，该引用（显式）允许共享DataContext，（隐式）允许从查询结果中共享实体对象，因为它们都来自同一数据上下文。
此外，DataContext实现了IDisposable，因此您确实需要管理它们的生存期。我们所有的web表单都有一个基类，其中一部分是datacontext属性（延迟创建）。这样，页面上的所有内容都可以共享，这是最常见的情况。上下文是在页面的OnUnload（）事件中手动处理的。
- 您不应该混合来自不同数据上下文的linq实体，如果您使用linq实体（如果数据上下文已被Dispose（）d of），则通常会遇到麻烦
我使用的是每线程上下文。设置起来很棘手，但它会清理所有需要与数据库对话的内容。
我在web场景中使用httpcontext，其他一切都使用线程上下文。我们构建了一个小框架，以便将数据上下文完全从表示/业务层抽象出来。