储存库和工作单元之间的关系

我将实现一个存储库，并且我想使用UOW模式，因为该存储库的使用者可以执行多个操作，因此我想一次提交它们。

在阅读了有关该问题的几篇文章之后，我仍然不知道如何将这两个元素联系起来，具体取决于文章是通过其他方式完成的。

有时，UOW是存储库内部的内容：

public class Repository
{
    UnitOfWork _uow;

    public Repository()
    {
       _uow = IoC.Get<UnitOfWork>();
    }

    public void Save(Entity e)
    {
        _uow.Track(e);
    }

    public void SubmittChanges()
    {
        SaveInStorage(_uow.GetChanges());
    }
}

有时它是外部的：

public class Repository
{
    public void Save(Entity e, UnitOfWork uow)
    {
        uow.Track(e);
    }

    public void SubmittChanges(UnitOfWork uow)
    {
        SaveInStorage(uow.GetChanges());
    }
}

其他时候，是UOW引用存储库的吗

public class UnitOfWork
{
    Repository _repository;

    public UnitOfWork(Repository repository)
    {
       _repository = repository;
    }

    public void Save(Entity e)
    {
        this.Track(e);
    }

    public void SubmittChanges()
    {
       _repository.Save(this.GetChanges());
    }
}

这两个要素有何关系？UOW跟踪需要更改的元素，并且存储库包含保持这些更改的逻辑，但是...谁叫谁？最后一个更有意义吗？

另外，谁来管理连接？如果必须在存储库中执行几项操作，我认为使用相同的连接甚至事务处理都比较合理，因此也许将连接对象放在UOW内，而将这个对象放在存储库内也很有意义。

干杯

回复：“ UOW跟踪需要更改的元素，并且存储库包含保持这些更改的逻辑，但是...谁叫谁？”

您了解这些类的基本职责。您说您已阅读的每篇文章都以不同的方式将它们连接在一起。这意味着关于“谁叫谁”的决定取决于您。

我会尝试根据“层”来勾勒出问题，同时还要遵循良好软件设计的基本原则，例如凝聚力，解耦，可重用性，单元可测试性等。

引用Eric Evans域驱动设计，（2004年）Addison Wesley，第69页：

[分层体系结构]的基本原理是，层的任何元素仅取决于同一层中的其他元素或该层“下”的层的元素。

我认为，UOW和Repo是两个非常不同的类，它们具有明确，独立的职责。首先，我不会调用任何一个。

我认为您需要一些第三类客户端（即a controller或service class），该类真正知道回购中的“何时以及获得什么”以及“何时”来保存交易。该客户端在体系结构中位置较高（因此可以了解更多类），并且可以在两者之间进行一些编排。

--------------------------------

         [Client]
           /   \
----------/---- \---------------
         /       \
        V         V
[Unit Of Work]  [Repo]


--------------------------------

这些方法最常见的是提供给UOW接口（通常是通过工厂构造的）。

通常，您可以从命令模式类/外观调用UOW接口上的方法。由于UOW只是将数据库IO推迟到以后才执行（以防止您进行长时间运行的事务或对数据库的多次调用，而这可能是不必要的），因此使用UOW的级别应与通常使用数据库的级别相同。

Microsoft在UOW模式上有一篇非常详尽的文章：

http://msdn.microsoft.com/zh-CN/magazine/dd882510.aspx