2

我是 Linq to sql 的新手。我的问题很简单。

将 DataContext 作为 DAL 中的公共静态成员以充当单例是个好主意吗？

4

5 回答 5

3

保持为单例并不是一个好主意DataContext，对于小型应用程序，您可能看不到任何后果，但是如果您的 Web 应用程序有很多用户要访问，则会导致内存泄漏。为什么？

DataContext基本上在后台实现了Unit Of Work ，它内部有内部缓存来跟踪实体的变化并避免在一个业务事务中往返数据库。长时间保持DataContext为静态，表示内部缓存会暂时增加，不会正常释放。

DataContext应保存在一个业务事务中并尽快释放。Web 应用程序的最佳实践是DataContext按要求保留。您还可以使用 IoC Container，大多数 IoC Container 都支持这一点。

于 2012-10-09T10:09:23.097 回答
2

在 DAL 中使用共享数据上下文时，我也经历过一件事。假设有两个用户 A 和 B。如果用户 A 启动并进行事务处理，那么用户 B 可以提交用户 A 所做的更改，这是使用静态 DataContext 的副作用。

于 2012-10-19T14:13:21.073 回答
1

您绝对不应该DataContext在 ASP.NET 等多线程应用程序中使用静态变量。 DataContext 的 MSDN 文档指出：

不保证任何实例成员都是线程安全的。

于 2012-10-09T10:14:34.510 回答
1

我通常尝试将数据访问类的功能组合在一起，并使该类 IDisposable。然后在构造函数中创建 DataContext，并在 dispose 方法中对 DataContext 运行 .dispose() 调用。

因此，当您需要该类中的某些内容时，您可以将其包装在 using 语句中，并使用相同的 DataContext 进行一系列调用。

这与使用静态 DataContext 的效果几乎相同，但意味着您不要忘记关闭连接，而且它似乎比使事物成为静态更 OO。

    public class MyDataAccessClass: IDisposable
    {
      private readonly DbDataContext _dbContext;

      public MyDataAccessClass()
      {
          _dbContext = new DbDataContext ();
      }

      public void Dispose()
      {
        _dbContext.Dispose();
      }

      public List<CoolData> GetStuff()
      {
           var d = _dbContext.CallStuff();
           return d;
      }
    }

然后在你的课上

   using(var d = new MyDataAccessClass())
   {
         //Make lots of calls to different methods of d here and you'll reuse your DataContext
   }
于 2012-10-09T10:10:31.453 回答
1

我建议您阅读有关“工作单元”模式的信息。即http://stuartharris4.blogspot.com/2008/06/working-together-linq-to-sql.html

于 2012-10-09T10:02:05.017 回答