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


17

我将实现一个存储库,并且我想使用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内,而将这个对象放在存储库内也很有意义。

干杯


Answers:


7

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

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

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

引用Eric Evans域驱动设计,(2004年)Addison Wesley,第69页

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

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

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

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

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


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

2

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

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

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

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

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.