spring mvc里面,为什么要单独出来一个service层调用dao再传给controller啊? 这样设计有什么好处?

如题,而且项目的业务逻辑一般是写在那个层里面?这些有比较完善的规定么?还是自己随便定?... 如题,而且项目的业务逻辑一般是写在那个层里面? 这些有比较完善的规定么? 还是自己随便定? 展开
 我来答
人世苦楚
2018-11-19 · TA获得超过239个赞
知道小有建树答主
回答量:213
采纳率:62%
帮助的人:63.6万
展开全部
在controller调dao其实也没问题,你还是没搞明白为什么要分层,在规范上来说,dao层只处理与数据库的交互,说白了就是怎么访问数据库,比如查询返回list,map.update,delete之类的,总体来说dao层几乎都是固定化的东西,整个框架可以只用一个dao接口和实现类(前提是你知道泛型),整个service层都调用同一个dao,因为访问数据库就那么几个需求.
service层又叫做业务层,本来组织sql之类的都是在这层写,但是很多人会写在dao层,其实是不对的,但是也没人会在意,而且直接写在dao层会看起来简单,实则从长久看会麻烦,但是谁会在意呢,这只是个注重效率的时代,service层的目的是重用,就比如你要分页查询,就会分为3个方法,查list,查数量,和一个把这两个组装的方法,这样分页的时候直接调用组装这个方法就可以了,其他地方要查list或者数量就可以调另外的方法,要是把这个都现在一个dao中那就只专用于查询这个分页了,所以从长久来说在service层写sql是很有必要的(但是时间有时候不能让你思考那么多),再有一个就是service是受数据库事务控制的,就比如你一个请求要改变两个表的数据,那在service层调用两次dao就可以了,如果在controller调用两次service那第一次成功第二次失败了是不是还要回滚第一次的改变?
controller 主要是处理一些不想关业务的逻辑,就比如你人员表中存的人员所属部门的id,你现在不可能把id直接显示到页面上,但是又想少些sql和少的代码,那你就可以差分页之后,再在controller中调用查部门的service,这样把分页查到的list遍历一下就可以把按id把部门插进去,这样的好处是你人员的查询service中的sql只关心人员表的数据,不用各种关联其它表(但是有时候还是需要关联的).
就说这么多吧,纯手打,第一次打这么多东西....
匿名用户
2018-10-12
展开全部

首先我们先知道spring的项目分层: 

按照MVC的设计理念来讲,由service服务层调用持久层dao,在由controller调用service,这符合MVC的分层结构也符合我们的编程习惯。

dao一般是做封装,service做业务,controller校验数据

要是controller直接调用dao的话,controller直接拿到数据这是不安全的,而且平常的一些业务逻辑处理不好处理,因为业务需求是实时改变的,把业务写在dao里还要全部更改业务信息,这样不仅不会节约成本还增加耦合,代码复用性也不高后期代码维护也困难。建议还是遵循MVC分层结构开发,尽管是少量数据也不建议直接调用dao。关于好处可以上别人博客借阅:网页链接

已赞过 已踩过<
你对这个回答的评价是?
评论 收起
爱情研习社1号
2019-02-04 · 爱是需要慢慢研习的一种能力!
爱情研习社1号
采纳数:5 获赞数:7

向TA提问 私信TA
展开全部
Controller层:负责具体业务模块流程的控制,即调用Service层的接口来控制业务流程。负责url映射(action)。

Dao层:负责数据持久化,与数据库进行联络的任务都封装在其中,Dao层的数据源以及相关的数据库连接参数都在Spring配置文件中进行配置。Dao接口中的方法都大同小异,因为对数据库的基本操作类似:insert、delete、update,select。                  在Dao层定义的一些方法,在Service层并没有被使用的情况:Dao层的操作经过抽象后基本都是通用的,在Dao层完成相关方法的定义,有利于支持后期Service层的扩展。(与相应的mapper对应)

Entity层:java对象,与数据库表一一对应,是其对应的实现类。即一个Entity就是对应表中的一条记录。

Service层:建立在DAO层之上,Controller层之下。调用Dao层的接口,为Controller层提供接口。负责业务模块的逻辑应用设计,首先设计接口,再设计其实现的类。

View层:表示层,负责前端jsp页面表示。
原因:

面向接口编程。表示层调用控制层,控制层调用业务层,业务层调用数据访问层。

Dao层设计与设计的数据库表,和实现类(对应的Entity或者JavaBean)一一对应。

View层与Controller层结合紧密,需要二者结合协同开发。Service层、Dao层和其他层次耦合很低,完全可以单独开发。
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
千古人文
2018-10-25 · TA获得超过388个赞
知道小有建树答主
回答量:233
采纳率:93%
帮助的人:88.3万
展开全部
一般来说,controller层是负责接收外部请求的,它的职责就是解析请求参数,根据参数判断要做哪些事件。但是它里面没有逻辑性。而Service层是负责处理业务逻辑的,主要是解决做什么,怎么做的问题。而dao是只负责和数据库打交到,把数据库的具体实现隔离开来。
这种设计的好处就是职责分离,修改各自的部分不会影响其它部分。比如controller层,一开始你使用的是json格式输入,但是以后想修改为protobuf,只需要修改这一个地方就行了。而service层,比如这个项目你是给A公司做的,现在B公司也要做一套差不多的,但有一些不一样的,你只需要把service层替换一下或继承一下就可以了,不会影响其它的。而Dao层,比如你现在使用的是mysql,将来公司有钱了,要换成oracle,只需要修改这一层就可以了。
想想,如果controller里面即做业务,又调用数据库,所有的东西都在一起,代码会非常混乱的。
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
百度网友02064e0
2018-11-22 · 超过22用户采纳过TA的回答
知道答主
回答量:66
采纳率:70%
帮助的人:18.3万
展开全部
设计dao层的目的是为了crud方法接口话,方便实现方法,默认的开发模式就是这样,而service才是真正的执行者,这样的实现方式是为了将事务处理最小单元化,方便管控,将数据传给controller才能真正的消费数据,因为controller层一般是不可以事务处理的,原因是,如果controller实现了接口,那么就spring就不会对其进行代理(其实是代理了,但是走了jdk代理,没有使用cglib),这样就不存在aop对其声明式事务了,如果没有实现接口,那还好办,可以实现事务处理,而且大多数的spring都不是独立开发,基本上都要结合mvc等手法,那么在不同的application扫描的时候呢,容易多重扫描和功能覆盖扫描,这样的话,导致service层也不存在事务处理了。
还希望能帮到你,望采纳
已赞过 已踩过<
你对这个回答的评价是?
评论 收起
收起 更多回答(34)
推荐律师服务: 若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询

为你推荐:

下载百度知道APP,抢鲜体验
使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。
扫描二维码下载
×

类别

我们会通过消息、邮箱等方式尽快将举报结果通知您。

说明

0/200

提交
取消

辅 助

模 式