gpt4 book ai didi

c# - 为什么需要在 UnitOfWork EF 上实现 Dispose 模式?

转载 作者:太空宇宙 更新时间:2023-11-03 18:37:52 24 4
gpt4 key购买 nike

微软教程http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application建议实现处置模式,如下所示:

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);
}

为什么我应该这样做,为什么我不能简单地处理上下文和足够的,如果我只使用会发生什么:

context.Dispose()

微软dispose模式的实现目标是什么?

最佳答案

你可以只使用...

    public void Dispose() // IDisposable implementation
{
context.Dispose();
}

...没有虚拟 Dispose 重载并且没有私有(private) disposed 标志,因为

  • 上下文本身会检查 Dispose 是否已被调用,以便在第二次调用时不会发生任何事情,也不会抛出异常
  • 上下文类有自己的终结器,如果您没有显式调用 Dispose,它将确保在垃圾回收时释放数据库连接

顺便说一句,最后一点并不意味着您根本不需要调用 context.Dispose(),因为垃圾收集器最终确定上下文的时间点是不确定的,它可能会晚于您创建新上下文实例并将其与相同实体一起使用的时间点——这可能会导致一些麻烦。所以:始终显式或通过 using block 处理上下文。

我也怀疑 GC.SuppressFinalize(this); 在这里有任何效果,因为你的类和基类中都没有终结器,所以没有什么可以抑制的。

在我看来,您示例中的模式是一个片段(缺少终结器/析构函数实现),如果您必须在类中处理自己的非托管资源,这可能很有用。但是对于您的 UnitOfWork 类,您不必这样做。非托管资源(数据库连接)由上下文管理,您只需通过调用 context.Dispose() 将工作委托(delegate)给它。

关于c# - 为什么需要在 UnitOfWork EF 上实现 Dispose 模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12770267/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com