spring mvc里面,为什么要单独出来一个service层调用dao再传给controller...

发布网友 发布时间：2022-04-27 03:16

我来回答

共15个回答

热心网友 时间：2022-04-07 18:46

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

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

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

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

热心网友 时间：2022-04-07 20:04

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

热心网友 时间：2022-04-07 21:39

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层和其他层次耦合很低，完全可以单独开发。

热心网友 时间：2022-04-07 23:30

有些朋友可能会问为什么要分层呢？我本来可以在一个地方写完的东西，非要散落在各个层中，都在一起不是挺好的吗，而且开发效率也比较高啊~
跳来跳去的我脑子都晕啦。。。
这就是为什么有人会把所有的东西都扔在一个层里，比如controller层。。。
其实我们可以在jsp上把所有的逻辑以及数据库操作,数据展示全部写在一起，耦合在一起，这样开发起来貌似更快，
但是维护性非常差，有朝一日想改一个小地方，牵一发而动全一身，隐患很高，无法快速定位问题。
因此我们需要分层。
分层了之后，你理论上改了持久层的东西，逻辑层是不用变动的。
每个Dao类是跟每个表走，Dao的每个方法里就一个个的简单sql，不包含任何业务逻辑，可以被不同的service复用和调用。
经过抽象后基本上都是通用的，因而我们在定义DAO层的时候可以将相关的方法定义完毕，
这样的好处是在对Service进行扩展的时候不需要再对DAO层进行修改，提高了程序的可扩展性。
提高了程序的可扩展性。具体什么时候做这些操作，怎么做这些操作都由Service来处理。
（就像郭德纲的相声里的一句话：“行了，你甭管了”）
而Service则不是，一个Service里可以会调用多个不同的，完成特定的业务逻辑，事务控制，
封装Service层的业务逻辑有利于通用的业务逻辑的性和重复利用性
同时，一个Service的方法也有可能被多个Controller的方法来调用。
逻辑出问题就在Service找问题，数据库，sql有问题就在Dao层找问题，
参数解析错误，跳转错误，就在Controller上找问题。
这样快速定位问题，互不干扰。
---------------
分层架构（这里会延伸到更广阔的架构）：
回头项目玩大了，怎么办？拆！！！
具体可以搜一下：maven分模块开发，怎么玩代码依赖，怎么玩微服务，怎么玩SOA，怎么玩RPC，怎么玩bbo。
web项目发展有几个阶段啊
第一个阶段（单一应用架构）：
所有代码都耦合在一个项目里，放在一台服务器上，这种all in one的方式是有好处的。
创业初期，不用什么架构，走敏捷开发，最快速的实现需求才是王道。
你甭管我有多烂，我至少能跑起来，我至少能在*上让你访问，让你使用。
当然了，初期的访问量很少，节省部署和运维成本才是王道呀。
听阿里的讲座，说淘宝的前期的版本用的就是一台PC机作为服务器，所有的功能耦合在一个项目里，
每次往生产环境上发版本，要上传一个600mb的包，呵呵。
第二个阶段（垂直应用架构）：
哎哟，不错哦。自己的儿子被越来越多的人访问，访问量激增，一台服务器扛不住了，
没事，我们可以玩负载均衡，玩集群。
但是！这种性能加速度其实会变得越来越小，因为你的项目是耦合在一起的。
这时，我们需要拆分项目，这里又有2个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习分布式架构中，未完待续。

热心网友 时间：2022-04-08 01:38

spring mvc 里面的 mvc 是有其意义的。

mvc全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

可能你注意到了，这里面并没有service，因为mvc概念也是从桌面软件开发中移植过来的，所以在应用到网络应用开发中，进行了一些改变，service层就是新演变出来的， service负责业务逻辑处理，如果没有service层，那要把业务代码放到controller中，一些公共的方法就无法实现共享，总的来说，service的出现就是为了代码重用。

至于是属于模型层的，也是一样受用于分层的概念，分层的优势有两个：解耦代码、实现重用。

MVC只是一种设计规范，不是硬性的，比如：如果项目很小，那可以没有service。

热心网友 时间：2022-04-08 04:03

一般来说，controller层是负责接收外部请求的，它的职责就是解析请求参数，根据参数判断要做哪些事件。但是它里面没有逻辑性。而Service层是负责处理业务逻辑的，主要是解决做什么，怎么做的问题。而是只负责和数据库打交到，把数据库的具体实现隔离开来。
这种设计的好处就是职责分离，修改各自的部分不会影响其它部分。比如controller层，一开始你使用的是json格式输入，但是以后想修改为protobuf，只需要修改这一个地方就行了。而service层，比如这个项目你是给A公司做的，现在B公司也要做一套差不多的，但有一些不一样的，你只需要把service层替换一下或继承一下就可以了，不会影响其它的。而Dao层，比如你现在使用的是mysql，将来公司有钱了，要换成oracle，只需要修改这一层就可以了。
想想，如果controller里面即做业务，又调用数据库，所有的东西都在一起，代码会非常混乱的。

热心网友 时间：2022-04-08 06:44

设计层的目的是为了crud方法接口话，方便实现方法，默认的开发模式就是这样，而service才是真正的执行者，这样的实现方式是为了将事务处理最小单元化，方便管控，将数据传给controller才能真正的消费数据，因为controller层一般是不可以事务处理的，原因是，如果controller实现了接口，那么就spring就不会对其进行代理（其实是代理了，但是走了jdk代理，没有使用cglib），这样就不存在aop对其声明式事务了，如果没有实现接口，那还好办，可以实现事务处理，而且大多数的spring都不是开发，基本上都要结合mvc等手法，那么在不同的application扫描的时候呢，容易多重扫描和功能覆盖扫描，这样的话，导致service层也不存在事务处理了。
还希望能帮到你，望采纳

热心网友 时间：2022-04-08 09:42

主要是把各个功能分开，便于以后维护，每个包处理同类的事情，比如说，处理与数据库相关的操作，service处理业务逻辑的操作，controller处理响应操作，pojo处理实体类对应数据库。
项目的业务逻辑一般都写在service层中，service就是处理业务逻辑的，service中比较常用有级联删除等，而这些没有一个较完善的规定，这些是随着开发的深入了解逐渐形成的一种不成文的规定，主要是方便维护和开发！

热心网友 时间：2022-04-08 12:57

分层没有一定之规，看架构师的设计了。不过按照我的理解业务逻辑应该在service这一层，service下面是层，不要把逻辑写到层里面去。

热心网友 时间：2022-04-08 16:28

controller控制器 一般接收请求,转发，返回数据等操作
service层处理业务逻辑
层负责数据库 增删改查
service 都会有实现类，这就是MVC设计模式，如果你不知道为什么要这么设计，那你先了解下什么是MVC

热心网友 时间：2022-04-08 20:16

面向对象编程原则：

单一职责原则

里氏替换原则

依赖倒置原则（高层模块不应该依赖低层模块）

接口隔离原则（客户端不应该依赖它不需要的接口）

迪米特法则（尽量降低类与类之间的耦合）

开闭原则（对扩展开放，对修改关闭）

理想的面向对象应该是高内聚低耦合的，之所以采用分层设计就是为了实现这一目标。

热心网友 时间：2022-04-09 00:21

完美的架构就是controller只与前台做交互，不写业务逻辑
具体业务逻辑实现就放在service层，这样层次清晰，而且可以把service层可以注入到不通的controller，提高代码复用率，事物一般也配置在service
大的项目一般都遵循这个规则，提高代码可读性，，，，如果你非要把所有代码都写在controller层 系统也能运行 不会报错

热心网友 时间：2022-04-09 04:42

service层作用就一个，处理复杂的业务逻辑。
在比较大型的系统中，由于处理的逻辑很复杂，一次请求可能要多次操作数据库，而如果就把这些调用层的代码写到action中，可是可以，但是不利于代码的维护和可以复用性，所有一般都会在层和action中间加上一个service层，将一些复杂的逻辑交给service层处理。

热心网友 时间：2022-04-09 09:20

这样的话，如果你不想用springmvc换了struts2。那么service以后的都可以不动。
另外如果你有其他代码。例如定时的批处理。jms监听程序，都可以使用service。
如果你都没有，那么多一点代码量也可以多收一点钱。

热心网友 时间：2022-04-09 14:15

层操作数据库层，设计尽可能的保证方法的单一性，低耦合性；
service层可以根据具体业务将层的方法组合使用，一般service层的实现都是基于接口的，也就是所谓的面向接口编程。设计好的接口，由具体的类来实现。
controller层是http请求的入口，一般在这一层不会写业务代码，直接接入数据，由后方service层处理。这一层可以去写一些数据校验代码，如有问题直接返回或者抛出异常。代码无需再往下走。