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

假设我有两个服务类：

UserService
ProductService

如果在我的ProductService类中注入UserService，这是错误的吗

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


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

}

---

我知道，作为一种替代方法，我可以创建另一个同时注入UserService和ProductService的类，但是为这个类命名是非常棘手的：）在SOA世界中，这些类型的类有名字吗？

您所描述的就是所谓的

---

顺便说一句，什么是SOA？

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

---

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

使用您提到的spring将一个服务注入到另一个服务中，这两个服务只在所使用的接口范围内耦合

如果需要更多的解耦，可以考虑使用消息在这两个服务之间传递

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

虽然弱类型消息会增加解耦，但这意味着您和您的客户机将放弃编译时检查，调试问题在运行时会很麻烦（1）如果在我的ProductService类中插入UserService，这是否错误

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


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

}

这本身没有问题，但有以下警告：

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

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

是的，正如前面提到的，您可以将这个类称为中介，因为类似乎描述了这一点

---

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

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

如果您知道其他服务Java级接口，那么引入紧密耦合的风险也很大。

---

例如，用户服务的返回类型是什么？它是属于用户服务的另一个接口吗？您是否在产品服务代码中传递了它？

如果您避免循环依赖，我看不出它有什么问题。就您针对接口进行编码而言，我看不出这是有问题的。我们不应该和具体的实现有直接的联系。我们可以依赖接口。我相信它是面向服务的体系结构。它在标记描述中：）