asp.net-mvc - UnitOfWork 作为存储库的容器

Question

我有一个看起来像这样的解决方案:

项目1 <—>共享项目<—>项目2

共享项目不是独立的，它通过服务层向其他项目公开其功能，该服务层接受由其他两个项目注入(inject)到构造函数中的 IUnitOfWork:

public SharedService (IUnitOfWork unitOfWork)
{
   ... do stuff ...
}

我遇到的问题是 Project1 和 Project2 有一组重叠但不同的存储库:

项目1: SharedRepository、RepositoryA、RepositoryB ...

项目2: SharedRepository、RepositoryX、RepositoryY ...

我一直看到implementations of Unit Of Work它扮演存储库容器的角色——您传递 UoW，然后通过公开它们的公共(public)属性访问存储库:

unitOfWork.SharedRepository.GetSomething();

这种方法的结果是您最终会得到一个工作单元的界面，如下所示:

public interface IUnitOfWork
{
    ISharedRepository SharedRepository();
    IRepositoryA RepositoryA();
    IRepositoryB RepositoryB();
    IRepositoryX RepositoryX();
    IRepositoryY RepositoryY();

    ... etc ...
}

这就是我遇到麻烦的地方:接口(interface) IUnitOfWork 现在强制 Project1 和 Project2 实现彼此的存储库。 因此，在我看来，使用工作单元作为存储库容器的方法可能是一个有缺陷的概念。

我想到了一些可能的替代方案:

1) 将 IUnitOfWork 分成 3 部分(IProject1UnitOfWork、IProject2UnitOfWork、ISharedUnitOfWork)，然后让服务层接受 ISharedUnitOfWork 参数。看起来很乱，但它可能会起作用。

2) 将 UnitOfWork 转变为类似于服务定位器的东西，它在其中维护存储库的集合，并且您可以注册所需的内容。然后，UoW 的使用者检索它需要的任何存储库。

3)将工作单元和存储库独立注入(inject)到服务层构造函数中:

public SharedService (IUnitOfWork unitOfWork, ISharedRepository repository)
{
   ... do stuff ...
}

遇到这样的情况，你们会怎么处理？我倾向于选项#3。它需要传递更多的东西，但替代方案似乎不太优雅。

Answer 1

So it appears to me that the approach of using Unit of Work as a container for repositories may be a flawed concept.

对我来说也是如此。您的示例中的工作单元也是一个伪服务定位器(通常已被视为反模式)，因此它违反了 SRP。 UoW 只是您想要放入其中的任何用例的事务包装器，它不应该了解有关存储库或用例中的任何内容的任何信息。

参见德米特里的回答:How does unit of work class know which repository to call on commit?

所以，对我来说绝对是选项 3。