避免服务类

说之间的紧耦合我有2个服务类：避免服务类

UserService 
ProductService

它是错的，如果我ProductService类中我注入UserService？

public class ProductserviceImpl implements ProductService { 


    @Autowired 
    UserService userService; 


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

}

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

来源

2012-10-17 loyalflow

只要你避免循环依赖，我没有看到任何错误。 –

只要你是对接口编码我没有看到这是有问题的。我们不应该与具体实施直接相关。我们可以对接口有依赖关系。 – raddykrish

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

服务可以帮助对方，以便为您提供最终结果。另外，正如JB Nizet所说，如果没有循环依赖关系，没有问题。

来源

2012-10-17 20:57:07 Alex

你所描述的是Mediator Pattern。

btw什么是SOA？

来源

2012-10-17 20:53:28 tozka

我相信它是面向服务的架构 – Alex

它在标签说明:) – Reimeus

使用像上面提到的弹簧将一个服务注入另一个服务将会耦合，这2个服务仅在所使用的接口范围内。

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

消息可以是强类型的值等对象/ XML与架构或弱类型就像一个HashMap

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

来源

2012-10-18 08:44:08

1）如果在我的ProductService类中注入UserService，它是错误的吗？

没有什么不对的本身，有以下注意事项：

要知道，你可能会潜在地在一个班做得太多（这里是ProductService）方向飞去
注意不要引入循环依赖（你不应该使UserService也依赖于ProductService）
通过将你的依赖连接到接口而不是具体类来限制紧密耦合（在这里你是自动装配UserService而不是UserServiceImpl，它很好）

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

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

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

来源

2012-10-18 17:21:23 Jay

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

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

来源

2012-10-23 19:57:42

回答

相关问题