Web应用程序中的LinqToSql静态DataContext
在我遇到的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就越多，我认为你是对的。 但是在我inheritance的应用程序中，这让人感到困惑，因为在每个方法的开头，他们都在重新查询数据库以获取信息，然后修改datacontext的实例并在其上提交更改。
从这一点来看，我认为应该不鼓励使用这种方法，因为它给人的错误印象是datacontext是静态的并且在请求之间保持不变。 如果未来的开发人员认为在方法开始时重新查询数据是因为他们认为数据已经存在，那么他们可能遇到问题而不理解原因。
所以我想我的问题是，如果在未来的发展中不鼓励这种方法吗？
这不是静态副本。 请注意，该属性从Context.Items中检索它，这是每个请求。 这是DataContext的每请求副本，可通过静态属性访问。
另一方面，此属性假设每个请求只有一个线程，这可能永远不会成立。
DataContext很便宜，通过这种方式缓存它不会获得太多收益。
我已经做了很多Linq to Sql网络应用程序，我不确定你的工作是否合适。
datacontext应该跟踪您对对象所做的更改，并且在此实例中不会这样做。
所以当你点击提交更改时，它不会知道你的任何对象在哪里更新，因此不会更新数据库。
您必须在断开连接的环境（如Web应用程序）中使用datacontext执行一些额外的工作。 更新最困难，但并不是那么糟糕。 我不会缓存，只是重新创建它。
此外，上下文本身不是事务性的，因此理论上可能会在另一个请求上发生更新，并且您的更新可能会失败。
我更喜欢创建一个Page基类（从System.Web.UI.Pageinheritance），并公开一个DataContext属性。 它确保每页请求有一个DataContext实例。
这对我来说效果很好，这是一个很好的平衡恕我直言。 您可以在页面末尾调用DataContext.SubmitChanges（）并确保所有内容都已更新。 您还确保一次为一个用户进行所有更改。
通过静态执行此操作会导致痛苦 – 我担心DataContext将失去对更改的跟踪，因为它试图同时跟踪许多用户的更改。 我不认为它是为此设计的。