2

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

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

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

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

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

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

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

我不断看到工作单元的实现，它扮演着存储库容器的角色——你绕过 UoW，然后通过公开它们的公共属性到达存储库：

unitOfWork.SharedRepository.GetSomething();

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

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

    ... etc ...
}

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

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

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

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

3）将工作单元和存储库独立注入服务层构造函数：

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

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

4

1 回答 1

2

所以在我看来，使用工作单元作为存储库容器的方法可能是一个有缺陷的概念。

我也是。您示例中的工作单元也是一个伪服务定位器（通常已被视为反模式），因此它违反了 SRP。UoW 只是您想要放置在其中的任何用例的事务包装器，它不应该知道任何关于存储库或用例中的任何内容的信息。

请参阅 Dmitry 的回答：工作单元类如何知道提交时要调用哪个存储库？

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

于 2013-03-14T15:16:16.850 回答