关于在 Service 中调用 Service 是否符合最佳实践？

[ByteCat]

自己在学习 Spring Boot 的开发，最近使用到了 MyBatis Plus 这个包，它有自带通用 Mapper 和 通用 Service。

那么，如果我在自己的 Service 中去调用其通用 Service 是否符合最佳实践，还是说以 Service 调用 DAO 为更好的选择？

[abcbuzhiming]

没有事务问题时，你可以这么做，有事务的时候你要当心事务传递失效问题。一般情况下有事务的情况我都是自建一个 service 然后调用多个 dao 来完成事务，代码会有冗余，但是足够安全，而且业务隔离，不会影响到其他

[mr253727942]

@abcbuzhiming 为何会失效呢

[mreasonyang]

可以再抽象出一个仓储层或应用服务层

[CStarter]

我们公司的不允许 service 调用其它 dao

[mmdsun]

service 调 service 可以接受。调 dao 不推荐

[gundam0603]

service 调 service 可能会有 循环引用的问题，当然用延迟加载就没事，不过总觉得少优雅。。。。
那个事务传递失败的话 ，service 调 service 不会有问题，有问题的是调用 this ,自调用的时候不走代理类。
新版本的 spring 支持注入本类，可以注入本类来走代理类。
感觉最规范的方法可能是 service 上再加一层,不过复杂了。
service 调 service 也可以用，就是要注意循环的问题.

[mysunshinedreams]

service 调用 service 分好层就还好。

[Aresxue]

从设计模式的单一职责原则来说不建议 service 的互相调用，相似的业务也应该由多个 Dao 重新组合完成实际业务，但是这样会带来大量冗余，好处是各个 service 完全独立没有相互耦合。相对的 service 互相调用则可以使得代码更为简洁业务上的相关性也体现在了代码上，在需要修改时只需要修改被依赖的 service，在重构时有很大的作用。业界对于耦合十分厌恶，比较互联网项目基本都拆除了外键，所以 service 只调用 dao 是一种更严谨的方式，service 之前的相互依赖一旦随着项目推进逐渐增多就会变成项目的负债让项目的推进越来越难。如果项目中没有严格规定的话，要考虑好两个 service 所对应的顶层业务是否需要这种关联性，需要则 service 调用 service，不然还是调用 dao 重新组合业务好了(这种方式调优时也有明显优势)。

[340244120w]

当然可以，而且很多时候也应该这样，不要为了设计模式而设计模式。

至于楼上说的缺点，spring 的依赖注入还是能处理 bean 之间的彼此依赖的;spring 也提供了事务传播控制的。