Question

在我遇到的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就越多，我认为你是对的。但是在我继承的应用程序中，它让人感到困惑，因为在每个方法的开头，他们都在重新查询db以获取信息，然后修改datacontext的实例并在其上提交更改。

从这一点来说，我认为应该不鼓励使用这种方法，因为它给出的错误印象是datacontext是静态的并且在请求之间保持不变。如果未来的开发人员认为在方法开始时重新查询数据是因为他们认为数据已经存在，那么他们可能遇到问题而不理解原因。

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

Answer 1

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

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

Answer 2

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

Answer 3

我做了很多Linq to Sql网络应用程序，我不确定你的工作是否有效。

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

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

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

Answer 4

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

Answer 5

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

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

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

Web应用程序中的LinqToSql静态DataContext

5 个答案: