Java Spring 设计：多合一组件？

Question

有时 Spring 组件可能如下所示：@Servicepublic final class SomeService {    @Autowired    private SomeService2 someService2;    @Autowired    private SomeService3 someService3;    @Autowired    private SomeService4 someService4;    // … and many other services    @Autowired    private SomeDao someDao;    @Autowired    private SomeDao2 someDao2;    @Autowired    private SomeDao3 someDao3;    // … and many other DAOs}换句话说，Spring 组件有很多服务和 DAO，这些服务和 DAO 在其他 Spring 组件中大部分是重复的。恕我直言，它有以下缺点：用于自动装配大多数相同组件的不必要（样板）代码有时由于组件之间的循环引用，可能会出现 Spring 上下文加载错误如何使用组合所有服务或所有 DAO 的一体化组件。它将仅包含指向 Spring 组件的链接，其中没有任何业务逻辑：@Servicepublic final class AllServices {    @Autowired    private SomeService2 someService2;    @Autowired    private SomeService3 someService3;    @Autowired    private SomeService4 someService4;    // … and many other services    // get methods to get some service    public someService getSomeService(){};并将其注入其他组件：@Servicepublic final class SomeService {    @Autowired    private AllServices serv;    @Autowired    private AllDaos daos;    @Autowired    private Environment env;// inside some code…serv.getSomeService().processData();恕我直言，如果没有循环引用问题，它看起来会更简洁……这种方法有什么优点和缺点？

Answer 1

第二种方法可能看起来很吸引人，首先想到的是众所周知的外观模式，所以我完全可以理解这一点。

但是，我认为第一种模式实际上会更好地工作，原因如下：

1. 你说“万能”的服务可以解决循环依赖

   好吧，循环依赖通常指向错误/糟糕的设计，并且是代码本身的味道，因此将其隐藏在外观后面不会改善系统，解决循环依赖会。此外，如果从由“AllServices”调用的实际服务中，您需要调用其他服务（同样，保留了糟糕的设计），那么代码可能会再次通过 AllServices，因此循环依赖仍然存在。

2. 使用第二种设计假设这个“AllServices”类将被系统的所有组件使用，但在这种情况下，它变成了一个“一个中心点”，并且在这个类中重构可能会变得疯狂——所有组件/他们的测试可能会受到影响

3. 此服务的初始化本身可能会变得一团糟，因为您可能不想维护具有 20-30 个输入参数的构造函数，您将求助于字段注入（如示例中），这本身就很糟糕，因为如果你想以某种方式初始化它，可能来自测试，或者你想知道什么应该被模拟，什么不是，以什么顺序，等等。

Answer 2

第二种方法可能看起来更干净，但很难知道哪个服务连接到服务/DAO，因此很难重构或执行/决定任何更改将导致哪个回归。这意味着它会影响软件的灵活性

这是一个重要的差异使不同选择第一个选项恕我直言