为什么我想将 UnitOfWork 与 Repository Pattern 一起使用？

Question

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

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

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 与 Repository Pattern 结合使用的理解是跨多个存储库执行操作——这种行为似乎与 @Ladislav Mrnka 对 Web 应用程序的建议相矛盾：

对于 Web 应用程序，每个请求使用单个上下文。对于 Web 服务，每次调用使用单个上下文。在 WinForms 或 WPF 应用程序中，每个表单或每个演示者使用单个上下文。可能有一些特殊要求不允许使用这种方法，但在大多数情况下这就足够了。

查看完整答案here

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

我的存储库在 IoC 中注册为临时存储库，因此我应该为每个请求获取一个新存储库。如果这是正确的，那么我应该为每个请求获得一个新的上下文（上面的代码），然后处理它——也就是说......是否遵循上述约定？

Answer 1

ObjectContext/DbContext 是 UnitOfWork 模式的实现。它封装了几个操作，并确保它们在一个事务中提交到数据库。

您唯一要做的就是将其包装在您自己的类中，以确保您不依赖于其余代码中的特定实现。

在您的情况下，问题在于您的Context 不应该被您的Repository 处理掉。 Repository 不是实例化Context 的那个，所以它也不应该丢弃它。封装多个存储库的UnitOfWork 负责创建和处置Context，您将在UnitOfWork 上调用Save 方法。

代码可能如下所示：

using (IUnitOfWork unitOfWork = new UnitOfWork())
{
   PersonRepository personRepository = new PersonRepository(unitOfWork);
   var person = personRepository.FindById(personId);

   ProductRepository productRepository = new ProductRepository(unitOfWork);
   var product= productRepository.FindById(productId);

   p.CreateOrder(orderId, product);
   personRepository.Save();
}

Answer 2

如果我想在存储库跨一个 Web 请求共享相同的上下文实例时将上下文的 SaveChanges 推离存储库，我会使用简化的 UoW。

我想您的存储库中有类似 Save() 方法的东西，看起来类似于 _customObjectContext.SaveChanges()。现在让我们假设您有两种方法，其中包含业务逻辑并使用 repos 来持久化 DB 中的更改。为了简单起见，我们将它们称为MethodA 和MethodB，它们都包含相当多的用于执行某些活动的逻辑。 MethodA 在系统中单独使用，但由于某种原因也被MethodB 调用。发生的情况是MethodA 将更改保存在某个存储库中，并且由于我们仍然在MethodB 中所做的相同请求更改，在它调用MethodA 之前，无论我们是否想要它也将被保存。所以在这种情况下，我们无意中破坏了MethodB 内部的事务，使代码更难理解。

我希望我描述得足够清楚，这并不容易。无论如何，除此之外，我看不出为什么 UoW 会对您的情况有所帮助。正如 Dennis Traub 非常正确地指出的那样，ObjectContext 和 DbContext 实际上是 UoW 的实现，因此您可能会在自己实现时重新发明轮子。

Answer 3

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

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

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