Web 应用程序中的 LinqToSql 静态 DataContext答案

【问题标题】：LinqToSql static DataContext in a web applicationWeb 应用程序中的 LinqToSql 静态 DataContext
【发布时间】：2010-10-30 18:24:19
【问题描述】：

在我遇到的一个web应用程序中，我发现以下代码在处理LinqToSQL时处理DataContext

public partial class DbDataContext
  {
    public static DbDataContext DB
    {
      get
      {
        if (HttpContext.Current.Items["DB"] == null)
          HttpContext.Current.Items["DB"] = new DbDataContext();
        return (DbDataContext)HttpContext.Current.Items["DB"];
      }
    }
  }

然后在以后引用它：

DbDataContext.DB.Accounts.Single(a => a.accountId == accountId).guid = newGuid;
DbDataContext.DB.SubmitChanges();

在处理 LinqToSQL 时，我一直在研究最佳实践。

我不确定这个在处理 DataContext 不是 ThreadSafe 并保留它的静态副本时所采取的方法。

这是采用 Web 应用程序的好方法吗？

@Longhorn213 - 根据你所说的以及我对 HttpContext 的了解越多，我认为你是对的。但是在我继承的应用程序中，这令人困惑，因为在每个方法的开头，他们都在重新查询数据库以获取信息，然后修改该数据上下文的实例并提交更改。

因此，我认为这种方法不应该被劝阻，因为它给人一种错误的印象，即数据上下文是静态的并且在请求之间持续存在。如果未来的开发人员认为在方法开始时重新查询数据，因为他们认为数据已经存在，他们可能会遇到问题并且不明白为什么。

所以我想我的问题是，在未来的开发中应该不鼓励这种方法吗？

【问题讨论】：

这是一篇包含更多详细信息的精彩帖子：blog.stevensanderson.com/2007/11/29/…
今晚我们刚刚推出了这个概念的一个变体。

标签： c# asp.net linq-to-sql datacontext

【解决方案1】：

我更喜欢创建一个 Page 基类（继承自 System.Web.UI.Page），并公开一个 DataContext 属性。它确保每个页面请求都有一个 DataContext 实例。

这对我来说效果很好，恕我直言，这是一个很好的平衡。您可以在页面末尾调用 DataContext.SubmitChanges() 并确保所有内容都已更新。您还可以确保所有更改一次只针对一个用户。

通过静态执行此操作会导致痛苦——我担心 DataContext 会丢失对更改的跟踪，因为它试图同时跟踪许多用户的更改。我不认为它是为此而设计的。

【讨论】：

他贴的代码不是静态DataContext。这是每个请求。只有一个请求，因此只有一个用户可以访问它。
是的，同意。它“隐藏”在静态方法后面。

【解决方案2】：

此外，上下文本身不是事务性的，因此理论上可能会在另一个请求上发生更新，而您的更新可能会失败。

【讨论】：

【解决方案3】：

我已经完成了许多 Linq to Sql 网络应用程序，但我不确定你所拥有的是否可以工作。

datacontext 应该跟踪您对对象所做的更改，但在这种情况下它不会这样做。

因此，当您点击提交更改时，它不会知道您的任何对象已更新，因此不会更新数据库。

您必须在断开连接的环境（如 Web 应用程序）中对数据上下文做一些额外的工作。更新是最难的，但并不是那么糟糕。我不会缓存并重新创建它。

【讨论】：

为什么它不知道请求期间所做的更改？
因为 datacontext 仅在请求时被访问，并且在回发周期后被销毁。您回到服务器，数据上下文不在那里跟踪对任何对象所做的更改。
我说，“在请求期间”。

【解决方案4】：

这不是静态副本。请注意，该属性从 Context.Items 中检索它，这是按请求进行的。这是 DataContext 的按请求副本，可通过静态属性访问。

另一方面，这个属性假设每个请求只有一个线程，这可能不会永远正确。

【讨论】：

【解决方案5】：

DataContext 的制作成本很低，以这种方式缓存它不会获得太多收益。

【讨论】：