使用SSH中， service层直接调用service层还是dao层，哪个更合理？

最近公司做项目时，遇到问题，在保存场景时需要一起保存其五类属性至各自属性表中，需要决定在场景的service模块调用属性模块的service还是dao,经查询，最终调用service层方法解决。原因如下：

按我的经验，service a不能调用b的dao层，只能调用b的service层实现业务。

因为b的service是对dao的CRUD封装，如果是单库的话service或许只是dao的代理，但如果有cache，跨库查询那显然调用dao b是不合理的，可以类比为视频系统调用用户系统，视频系统不关心用户系统的dao层实现机制，只要通过service层查询到用户信息即可。

另外你说的业务依赖确实有这样的困惑，但本身java类之间通讯就是有依赖关系的，或许如果service a业务依赖的service b业务太过于复杂时你可以再次抽象出service b的另外一个interface就ok了。

个人建议不同的模块之间还是service飞来飞起就好了，不要搞到模块A的service调用模块B的dao。简单的说就是为了遵循SOA，代码结构更清晰。长远点说以后不同模块之间拆分项目/独立成jar包也是好的。举个例子， 项目里面有两个模块：账号相关模块和消息相关模块。某个用户登录需要用到账号模块获取用户信息(AccountService.getAccountByxxx)，而且拉用户未读消息（messageService.getUnRead）。用户登录这个行为可以用一个facade包装"账号模块获取用户信息" & "拉用户未读消息"。搞一个UserBehaviorFacede就是了。其次，如果像题主这种问题， 是不是用一个facade包装一下， 而不是模块调来调去？

作者：林毅文
链接：https://www.zhihu.com/question/27139263/answer/35403419
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

参考如下：

java web项目开发中spring service层直接调用service层还是dao层，哪个更合理？

一个模块中的service层能不能相互引用?

其中提到的facade模式：

设计模式（九）外观模式Facade（结构型）