Question

我目前有一个多层MVC应用程序（Web，BLL，DAL），并试图了解如何正确使用dispose for DbContext。

有关于如何使用依赖注入执行此操作的大量信息。

我不确定我会使用DI（还）。因此，如果我到目前为止所做的事情是正确的，我为什么要努力解决。

以下是已完成的工作：

网络

在Controller中，实例化DbContext，并使用Dispose（）方法。

  private MyDbContext _context = new MyDbContext();
  ...
  ...

  protected override void Dispose(bool disposing)
  {
      if (disposing)
      {
       _context.Dispose();
      }
      base.Dispose(disposing);
  }

实例化BLL.service对象并将其传递给DbContext

BLL

实例化DAL.repository对象并将其传递给DbContext

DAL

此类继承自：IDisposable

并包含Dispose方法。

    private bool disposed = false;

    protected virtual void Dispose(bool disposing)
    {
        if (!this.disposed)
        {
            if (disposing)
            {
                _context.Dispose();
            }
        }
        this.disposed = true;
    }

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

背景原因：

控制器实例化DbContext，并将其传递给存储库类。更好的方式（即共享上下文），而不是每个存储库实例化自己的上下文。

问题：

我怀疑存储库类是否需要Dispose（）逻辑。 BLL怎么样？它有一个上下文对象，但只是传递它？这里需要Dispose（）逻辑。

即。控制器中的Dispose（）是否足够？或者在每个级别都需要Dispose？一般来说，如果我所做的是正确的？感谢。

Answer 1

尝试在创建DbContext时进行抽象，看看this和this

Answer 2

我怀疑存储库类是否需要Dispose（）逻辑。 BLL怎么样？它有一个上下文对象，但只是传递它？这里需要Dispose（）逻辑。

不。不需要。

dbContext没有任何昂贵的资源来保证其处置（例如连接打开）。一旦检索到数据，dbContext就会关闭其连接。即使在高负载下，性能增益也可以忽略不计。

在DbContext上使用Dispose（）的问题

公开dbContext的Dispose（）方法会引发将来调用的方法的潜在问题，从而有效地破坏了ORM的目的（无意中杀死了延迟加载器）。这个问题在共享dbContexts上很明显，其中一个存储库处理它，而其他一些存储库可能仍在使用它。

虽然某些特殊方案需要显式调用dbContext.Dispose（），但在大多数情况下它已经足够了。

MVC Dispose（）在没有DI的多层中

2 个答案: