我没有发现任何解决此特定问题的问题。 哪个更好：允许服务（或外观）访问多个 DAO（与数据库通信的类）或仅访问其他服务？
换句话说，我应该在不同的 Service 类之间引入相互依赖关系，还是通过向每个 Service 类注入多个 DAO（如果需要）来使 Service 类完全独立更好？
我发现这两种策略都可以完成工作，但我希望保持一致，并使应用程序尽可能模块化和可维护。
我认为允许或禁止一项服务调用另一项服务或多个 DAO 是主观的。 我试图避免不必要的代码或奇怪的耦合，只是为了满足一些有关层通信的规则，并且遵循创建简单、清晰的对象的基本面向对象原则通常会导致妥协。
如果服务 B 需要服务 A 中已包含的另一个功能，那么它应该调用它。我尝试减少服务之间的依赖关系，通常最终会定义一小组可以从其他服务调用的“基本”服务。
在服务中创建一个方法只是为了包装对 DAO 的调用是没有意义的（在我看来），因此我更喜欢让服务根据需要调用尽可能多的 DAO。同样，具有多个 DAO 的服务或方法表明需要重构某些内容或需要调整数据模型。
可以肯定的是，这方面有一些观点，但真正的“服务”方法应该是一个原子工作单元。如果他们正在创建一个相互依赖的网络来回和横向调用彼此，那么显然这些调用没有执行原子任务。我认为让“服务”使用它需要的任何 DAO 并没有什么错。创建一组“服务”-CRUD 方法来抽象 DAO，DAO 已经是 CRUD 方法的集合，而 DAO 本身可能抽象出 JPA 的抽象，您可以看到这可能是过多级别的非功能抽象。
这种方法有时确实会导致您构建多个服务共享的域中而不是服务中的共享“业务 bean”。这很好。
（我个人认为 JPA 已经让 DAO 的整个想法变得过时了，我们应该在服务中使用 EntityManager 吗？:) ）
这不是偏好问题，而是封装问题，使 DAO 可通过其相关服务进行访问。服务之间可以互相调用来访问其他服务功能，这可以在微服务中更详细地看到，这将是一个混乱的代码让每个服务访问任何 DAO 只会自找麻烦，特别是在大团队中，因此在编码标准服务时应该仅访问相关的 DAO，以实现代码的封装和隔离。