LINQ to SQL - 您的 DataContext 在哪里?

问题描述

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

I'm using LINQ to SQL in a data access object library. The library is used in both web (web application/web service) and non-web (windows service) contexts. Initially, I stored the DataContext on the current HttpContext since it permitted me to manage a fairly small unit of work (one web request) and avoided global objects in a web app. Obviously, this doesn't work in a Windows Service.

Rick Strahl 有一篇关于管理 DataContext 生命周期的好文章:http://www.west-wind.com/weblog/posts/246222.aspx.不幸的是，我无法确定最佳方法.由于他提到的原因，全局 DataContext 不起作用，每个线程的 DataContext 看起来很复杂并且可能比它的价值更麻烦，并且每个对象的实例似乎很繁琐 -当您将用于创建 DAO 的 DataContext 附加到该 DAO 以便它可以 update 或delete 稍后 - 更不用说，这种关系有一些令人不快的鸡与蛋的关系.

Rick Strahl has a nice article on managing the DataContext's lifetime: http://www.west-wind.com/weblog/posts/246222.aspx. Unfortunately, I can't make up my mind on the best approach. A global DataContext doesn't work for reasons he mentions, a per-Thread DataContext seems complicated and potentially more trouble than it's worth, and a per-object instance seems fussy - you lose some elegance when you attach the DataContext used to create a DAO to that DAO so it can update or delete later - not to mention, there's something unpleasantly chicken-and-eggish about the relationship.

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

Does anyone have personal experience that suggests one approach is better than another? Or better yet, does anyone have a fourth or fifth approach I'm not seeing? Where is the best place to store and manage your DataContext?

推荐答案

来自 有关 DataContext 类的 MSDN 文档 是我推荐的以下内容:

The guidelines from the MSDN documentation on the DataContext class are what I would recommend following:

一般来说，一个DataContext实例是旨在持续一个单位工作"但是您的应用程序定义那个词.数据上下文是重量轻，而且不贵创建.一个典型的 LINQ to SQL应用程序创建数据上下文方法范围内的实例或作为短期班级的成员表示一组相关的逻辑数据库操作.

In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.

因为 DataContext 是 IDisposable，我发现在 using 语句中创建和使用 DataContext 最容易一种方法，所以它可以被妥善处理.

Because DataContext is IDisposable, I find it easiest to create and use a DataContext in a using statement within one method, so it can be disposed of properly.

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

Also note that "any instance members are not guaranteed to be thread safe", so sharing one DataContext between multiple threads would be unwise.

这篇关于LINQ to SQL - 您的 DataContext 在哪里?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持html5模板网！