最近公司做项目时,遇到问题,在保存场景时需要一起保存其五类属性至各自属性表中,需要决定在场景的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层,哪个更合理?
其中提到的facade模式:
设计模式(九)外观模式Facade(结构型)