8

在我遇到的一个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 的了解越多，我认为您是对的。但是在我继承的应用程序中，这令人困惑，因为在每个方法的开头，他们都在重新查询数据库以获取信息，然后修改数据上下文的该实例并提交更改。

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

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

4

5 回答 5

6

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

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

于 2009-06-02T17:45:07.340 回答
0

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

于 2009-06-02T17:44:54.423 回答
0

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

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

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

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

于 2009-06-02T17:46:55.560 回答
0

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

于 2009-06-02T17:52:47.453 回答
0

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

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

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

于 2009-06-02T22:22:49.343 回答