避免服务类之间的紧密耦合答案

【问题标题】：Avoiding tight coupling between Service classes避免服务类之间的紧密耦合
【发布时间】：2012-10-17 20:47:56
【问题描述】：

假设我有 2 个服务类：

UserService
ProductService

如果我在我的 ProductService 类中注入 UserService 会出错吗？

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


  @Override
  public void someThing() {
      ..
      userService.otherThing(..);
      ..
  }

}

我知道作为替代方案我可以创建另一个同时注入 UserService 和 ProductService 的类，但是为这个类命名非常棘手:) 这些类型的SOA 世界中的类？

【问题讨论】：

如果你避免循环依赖，我看不出有什么问题。
就您针对界面进行编码而言，我认为这没有问题。我们不应该与具体的实现有直接的联系。我们可以依赖于接口。

标签： java spring spring-mvc soa

【解决方案1】：

1) 如果在我的 ProductService 类中注入 UserService 会出错吗？

这本身并没有什么问题，但需要注意以下几点：

请注意，您可能会朝着一个类做太多事情的方向前进（这里是 ProductService）
注意不要引入循环依赖（你不应该让 UserService 也依赖 ProductService）
通过将依赖项连接到接口而不是具体类来限制紧密耦合（这里您自动连接 UserService 而不是 UserServiceImpl，这很好）

2) 这种类型的类有名称吗（同时注入 UserService 和 ProductService）？

是的，如前所述，您可以将此类称为调解器，因为 Mediator Pattern 似乎描述了这一点。

您可以同时拥有低级服务和高级服务，将低级服务（ProductService、UserService）注入高级服务（例如，PurchaseOrderService 或 PurchaseOrderMediator）。或者，对于这种特殊情况，您可能会将产品服务视为依赖于 UserService 的单个高级服务。在这一点上，更多的是在您的业务逻辑和应用程序的上下文中哪个构造更cohesive。

【讨论】：

【解决方案2】：

对我来说，将服务注入另一个服务是没有问题的。正如您所说，这就是服务和 SOA 的重点。

服务可以互相帮助，以便为您提供最终结果。此外，正如 JB Nizet 所说，如果没有循环依赖，那也没问题。

【讨论】：

【解决方案3】：

您所描述的内容称为Mediator Pattern。

顺便说一句，什么是 SOA？

【讨论】：

我相信它是面向服务的架构
在标签描述中:)

【解决方案4】：

像您提到的那样使用 spring 将一个服务注入另一个服务将耦合，这两个服务仅在所使用的接口范围内。

如果您需要更多解耦，请考虑使用消息在 2 个服务之间传递。

消息可以像带有模式的值对象/xml 一样强类型化或者像 HashMap 这样的弱类型

虽然弱类型消息会增加解耦，但这意味着您和您的客户将失去编译时检查，并且在运行时调试问题会很麻烦

【讨论】：

【解决方案5】：

您描述的是面向对象的集成，很可能不是 SOA 集成。您可能会（并且应该避免）循环依赖的事实证明了这一点。

如果您的服务知道其他服务 Java 级别的接口，那么引入紧密耦合的风险也很大。例如，用户服务的返回类型是什么？它是属于用户服务的另一个接口吗？是在产品服务的代码中传递的吗？

【讨论】：