4

假设我有 2 个服务类：

UserService
ProductService

如果在我的 ProductService 类中注入 UserService 是不是错了？

public class ProductserviceImpl implements ProductService {


  @Autowired
  UserService userService;


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

}

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

4

5 回答 5

2

1) 如果在我的 ProductService 类中注入 UserService 是不是错了？

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

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

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

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

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

于 2012-10-18T17:21:23.607 回答
1

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

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

于 2012-10-17T20:57:07.053 回答
0

您所描述的称为Mediator Pattern。

顺便说一句，什么是 SOA？

于 2012-10-17T20:53:28.713 回答
0

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

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

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

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

于 2012-10-18T08:44:08.643 回答
0

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

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

于 2012-10-23T19:57:42.637 回答