这是一个创建于 2185 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 lihongjie0209 2019-10-23 17:48:33 +08:00 或许他们的高层 service 不叫 service， 叫其他的。 简单一点的 controller > service -> dao 复杂一点的 controller > service -> 叫什么都可以(low level service) > dao |
 | 2 nekolr 2019-10-23 17:52:52 +08:00 猜想：service 一般会包含事务的吧，service 调用 service 是不是需要考虑事务的传播 |
 | 3 passerbytiny 2019-10-23 18:12:36 +08:00 一旦你放飞了，用不了多久就会碰上鸡和蛋的问题A → B & B→ C &C→ A，调用链过长导致职责不明确的问题，以及任何面向函数编程回遇到的问题。 Service 是一个高内聚的独立单元。假如 A 调用了 B，那么：A 强依赖于 B，从而铁定是高耦合的； B 也可能要考虑到向其它 Service 返回数据（原本它只需要考虑向上层返回数据）从而降低了内聚程度。 |
 | 4 uyhyygyug1234 2019-10-23 18:14:12 +08:00 dimond 你搞些微服务互相调，也可以。公司之间还互相依赖呢。不要死循环了就行 |
 | 5 Aresxue 2019-10-23 18:31:58 +08:00 各有优劣，不做平级调用的好处是粒度更细，代码依赖更少，做优化的时候也更方便些，更符合单一职责原则。缺点就是开发代码量多，而且很可能会有冗余 |
 | 6 vanishxiaoma OP @passerbytiny ServiceB 中的一个方法在别的 Service 中都会用到 , 为了解耦 需要在每个用到的 Service 中都写一边吗?如果这样是不是违背了 代码复用的原则 |
 | 7 mmdsun 2019-10-23 18:46:55 +08:00 via Android 如果两个模块（ service ）之间没有直接关系，它们之间的联系完全是通过主模块（ controller ）的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。 如果一个 service 访问另一个 service 时，彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的，则称这种耦合为数据耦合，这种也是可以接受的，但是独立性没有第一种好。 （这种类比简单粗暴了。 |
 | 8 taogen 2019-10-23 20:04:09 +08:00 via iPhone 复用的代码作为公共父类 |
| 9 passerbytiny 2019-10-24 09:14:47 +08:00 @vanishxiaoma #6 如果 Service 层是独立设计的（至少可以利用 Mock 脱离上下层进行自主单元测试），那么这些共用的代码，可以抽取成 Service 层内部的独立类这些类只能被常规 Service 调用。（实际上，Controller/Action、Dao 层受限于框架只能是固定的单类模式，但从来没有人说过 Service 层也必须是单类模式。） 另外一种方式是在 Service 层和 Dao 层之间插入一层可选的 LowerService 层。 以上两种方式，都很容易步入另一个坑CommonService Hell。 Controller/ActionServiceDao，这是对应贫血领域模型的典型架构，它当初因为降低了 Java 的门槛而发扬光大，它之后因为暴漏的各种 Hell 以及面向过程编程的嫌疑而被多个（国外的）大佬批成了 SHI。现在研究它没啥意义，小项目建议 Controller/Action+SQL 模板（例如 Spring-Data-Jdbc ），大项目直接上领域模型设计。 |
 | 10 inwar 2019-10-24 10:04:08 +08:00 via Android 循环依赖要处理,模块过度耦合,调用链混乱。不如再加曾 manager |
Select Language