有什么更好：允许服务访问多个DAO或仅访问其他服务

Question

我没有发现任何有关此特定问题的问题。 更好的是：允许服务（或外观）访问几个DAO（与数据库通信的类）或仅访问其他服务？

换句话说，我应该在不同的服务类之间引入相互依赖关系，还是通过向每个服务类注入多个DAO（如果需要）来使服务类完全相互独立？

我发现这两种策略都可以完成这项工作，但我希望保持一致，并使应用程序尽可能模块化和可维护。

Answer 1

我觉得允许或禁止服务调用其他服务或多个DAO是主观的。 我试图避免不必要的代码或奇怪的耦合只是为了满足关于层通信的一些规则，并遵循基本的OO原则来制作简单，清晰的对象通常会导致妥协。

1. 如果服务B需要已经包含在服务A中的其他功能，那么它应该调用它。我尝试减少服务之间的依赖关系，并最终定义一组可以从其他服务调用的“基本”服务。

2. 在服务中创建一个方法只包含对DAO的调用是没有意义的（在我看来），因此我更愿意让服务根据需要调用尽可能多的DAO。同样，具有许多DAO的服务或方法表示应该重构的内容或需要调整的数据模型。

Answer 2

有一些观点可以肯定，但真正的“服务”方法应该是一个原子工作单元。如果他们正在创建一个相互依赖的网络，彼此向后和向侧面调用，显然调用不执行原子任务。我认为让“服务”使用它需要的任何DAO没有错。创建一组“服务”-CRUD方法，抽象DAO已经是CRUD方法的集合，它本身可能抽象出JPA的抽象，你可以看到这可能是一个太多级别的非功能抽象。

这种方法有时会导致您构建域中的共享“业务bean”而不是多个服务共享的服务。这很好。

（你能告诉我个人认为JPA已经让DAO的整个想法过时了，我们应该在服务中使用EntityManager吗？:)）