Design patterns 服务应该依赖于许多存储库，还是将它们分解？

我正在使用存储库模式进行数据访问。所以我基本上每个表/类都有一个存储库。我的UI目前使用服务类来实际完成任务，这些服务类是封装的，因此依赖于存储库。在许多情况下，我的服务只依赖于一个或两个存储库，所以事情不会太疯狂。不幸的是，我在UI中的一个表单希望用户输入跨越五个不同表的数据。对于这个表单，我创建了一个依赖于五个存储库的服务类。然后，服务中用于保存和加载数据的方法在所有相应的存储库上调用适当的方法

可以想象，这个服务中的save和load方法非常大。此外，对这个服务进行单元测试变得非常困难，因为我必须设置这么多假存储库

---

将这一单一服务拆分为几个较小的服务会是一个更好的选择吗？它会在UI层添加更多代码，但会使服务更小、更易于测试。

一种可能是按照您的建议分解服务，但是创建一个用于处理这些存储库的外观并保留单个服务也是合理的。这将允许您分离服务中的业务逻辑和数据操作，并可能在存储库中和存储库之间流动。

我想说，如果您可以将存储抽象到每个存储库中，而不是从服务中调用抽象，那么您就有了更易于测试和维护的代码，而无需在存储库中放入任何额外的代码用户界面

---

我目前有一个UI，它调用多个服务以将输入保存在一个表单中（异步），让它正常工作是一件痛苦的事情。最大的问题是处理验证和错误。第一位可能是正确的，但第二位失败。您必须返回并删除第一位，因为它已经保存。相信我，这是一种痛苦。

< P>我想我会集中在中间段落的两个句子：

首先，为什么服务类中的保存和加载方法“非常大”？你能把他们分开吗？也许有一些更小的单元可以单独测试。这可能意味着将服务分成若干子组件，您的服务将其大部分工作委托给这些子组件。您可能希望避免向UI层添加更多的代码，因为UI仍然能够与一个服务交互，但您可以单独测试所有组件

其次，为什么在您的测试工具中设置假存储库如此困难？你能简化一下吗？我经常使用构建器来设置类似但不完全相同的数据结构，以供测试使用。然后，您将得到这样的测试：“给定除差异X之外的常规设置，检查Y是否发生”

---

另一个想法是注意数据访问代码通常是非常重复的，并且通常可以根据数据库模式自动生成大部分代码。我们生成了许多基本数据访问层，包括用于测试的存储库类的伪实现。当然，我们必须手工编写性能关键位的代码，但这会减少很多繁琐的工作，并使模式的更改更容易处理。

我不希望每个表/类都有一个存储库类

每个“模块”或“根聚合”应该有一个存储库。也就是说，某个存储库可以覆盖远不止一个表。我们已将相关表分组到一个存储库中。例如，我们在不同表的顶部有一个RelationRepository，如Person、Company和OrderRepository，在表的顶部有Orders、OrderLines、FlightRepository，用于存储航班的所有数据，等等。 这是repositorypattern，因为根据域驱动设计，您应该希望使用它