Service 调用 Service 为什么有人不推荐

[vanishxiaoma]

[lihongjie0209]

或许他们的高层 service 不叫 service， 叫其他的。

简单一点的 controller > service -> dao
复杂一点的 controller > service -> 叫什么都可以(low level service) > dao

[nekolr]

猜想：service 一般会包含事务的吧，service 调用 service 是不是需要考虑事务的传播

[passerbytiny]

一旦你放飞了，用不了多久就会碰上鸡和蛋的问题——A → B & B→ C &C→ A，调用链过长导致职责不明确的问题，以及任何面向函数编程回遇到的问题。

Service 是一个高内聚的独立单元。假如 A 调用了 B，那么：A 强依赖于 B，从而铁定是高耦合的； B 也可能要考虑到向其它 Service 返回数据（原本它只需要考虑向上层返回数据）从而降低了内聚程度。

[uyhyygyug1234]

dimond

你搞些微服务互相调，也可以。公司之间还互相依赖呢。不要死循环了就行

[Aresxue]

各有优劣，不做平级调用的好处是粒度更细，代码依赖更少，做优化的时候也更方便些，更符合单一职责原则。缺点就是开发代码量多，而且很可能会有冗余

[vanishxiaoma]

@passerbytiny ServiceB 中的一个方法在别的 Service 中都会用到 , 为了解耦 需要在每个用到的 Service 中都写一边吗?如果这样是不是违背了 代码复用的原则

[mmdsun]

如果两个模块（ service ）之间没有直接关系，它们之间的联系完全是通过主模块（ controller ）的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。


如果一个 service 访问另一个 service 时，彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合，这种也是可以接受的，但是独立性没有第一种好。

（这种类比简单粗暴了。

[taogen]

复用的代码作为公共父类

[passerbytiny]

@vanishxiaoma #6 如果 Service 层是独立设计的（至少可以利用 Mock 脱离上下层进行自主单元测试），那么这些共用的代码，可以抽取成 Service 层内部的独立类——这些类只能被常规 Service 调用。（实际上，Controller/Action、Dao 层受限于框架只能是固定的单类模式，但从来没有人说过 Service 层也必须是单类模式。）

另外一种方式是在 Service 层和 Dao 层之间插入一层可选的 LowerService 层。

以上两种方式，都很容易步入另一个坑——CommonService Hell。

Controller/Action—Service—Dao，这是对应贫血领域模型的典型架构，它当初因为降低了 Java 的门槛而发扬光大，它之后因为暴漏的各种 Hell 以及面向过程编程的嫌疑而被多个（国外的）大佬批成了 SHI。现在研究它没啥意义，小项目建议 Controller/Action+SQL 模板（例如 Spring-Data-Jdbc ），大项目直接上领域模型设计。

[inwar]

循环依赖要处理,模块过度耦合,调用链混乱。不如再加曾 manager