asp.net - 为什么我想将 UnitOfWork 与存储库模式一起使用？

Question

我在网上看到了很多关于 UnitOfWork 和 Repo 模式的信息，但仍然不清楚为什么以及何时使用——这让我有些困惑。

考虑到我可以通过使用 DI 通过使用 IoC 来测试我的存储库，如本文 What are best practices for managing DataContext 中所建议的那样。我正在考虑将上下文作为对我的存储库构造函数的依赖项传递，然后像这样处理它？:

public interface ICustomObjectContext : IDisposable {}
public IRepository<T> // Not sure if I need to reference IDisposable here
public IMyRepository : IRepository<MyRepository> {}

public class MyRepository : IMyRepository
{
    private readonly ICustomObjectContext _customObjectContext;

    public MyRepository(ICustomObjectContext customObjectContext)
    {
        _customObjectContext = customObjectContext;
    }

    public void Dispose()
    {
        if (_customObjectContext != null)
        {
            _customObjectContext.Dispose();
        }
    }

    ...

}

我目前对使用 UnitOfWork 与存储库模式的理解是跨多个存储库执行操作 - 这种行为似乎与@Ladislav Mrnka 建议的 Web 应用程序相矛盾:

For web applications use single context per request. For web services use single context per call. In WinForms or WPF application use single context per form or per presenter. There can be some special requirements which will not allow to use this approach but in most situation this is enough.

查看完整答案here

如果我正确理解他，DataContext 应该是短暂的，并且基于每个请求或演示者使用(在其他帖子中也看到了这一点)。在这种情况下，存储库针对上下文执行操作是合适的，因为范围仅限于使用它的组件 - 对吗？

我的存储库在 IoC 中注册为临时存储库，因此我应该针对每个请求获取一个新的存储库。如果这是正确的，那么我应该为每个请求获取一个新的上下文(上面的代码)，然后处理它——也就是说......为什么我要使用 UnitOfWork 模式和存储库模式，如果我遵循上述约定吗？

Answer 1

据我了解，工作单元模式不一定涵盖多个上下文。它只是封装单个操作或——好吧——工作单元，类似于事务。

创建上下文基本上会启动一个工作单元；调用 DbContext.SaveChanges() 完成它。

我什至可以说，在当前的实现中， Entity Framework 的 DbContext/ObjectContext 类似于存储库模式和工作单元模式。