shiyun的gravatar头像
shiyun 2015-06-11 21:48:19

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

我的理解是:service层作为一个业务逻辑处理层,我若直接调用dao层,那么该业务只取出我所需要的数据,我若调用service层,那么就相当于一个业务依赖于另一个业务,耦合度不就高了?所以,到底哪个更合理,想听听你们的理解

所有回答列表(7)
最代码官方的gravatar头像
最代码官方  LV168 2015年6月11日

按我的经验,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了。

这个问题非常好,也是我一直想总结分享的,具体可以看下我分享的完整的java项目代码。

java开源微博系统weibo4j分享

分享一份完整的spring data jpa demo代码

评论(0) 最佳答案
Smail_的gravatar头像
Smail_  LV19 2015年6月12日

service层,这更符合MVC的理念,也符合我们编程的习惯,还有为了数据的安全性,也不允许controller对数据库做直接操作!——以上纯属个人见解!

Maxine丶男神的gravatar头像
Maxine丶男神  LV5 2015年6月12日

service层更合理

a3431265的gravatar头像
a3431265  LV2 2015年6月12日

个人觉得肯定是service层了, 如果直接调用dao。违背了MVC模式概念, 而且代码才真正的耦合性增加。换个思想来看,如果你直接调用了dao层. 那么平常的一些业务逻辑处理怎么办? 写在dao里面吗, 万一哪天业务需求改变了. 岂不是连dao全部都要改版.增加了开发的工作量,而且代码重用性不高.  只是个人理解哈.

chongzi的gravatar头像
chongzi  LV15 2015年6月13日

这个要看业务的复杂程度了,如果比较复杂,变动大,我感觉还是调用service,如果业务变动不太大,那就调用dao实现就可以了吧 

Jason_love的gravatar头像
Jason_love  LV2 2015年6月13日

调用service层,要严格执行mvc的分层结构,如果不分层直接调用dao层的话,容易出错,后期维护困难.只要严格分层,

不会容易出错

iterjiau的gravatar头像
iterjiau  LV1 2016年12月26日

调用service层更合理

顶部 客服 微信二维码 底部
>扫描二维码关注最代码为好友扫描二维码关注最代码为好友