spring mvc里面,为什么要单独出来一个service层调用dao再传给controller啊? 这样设计有什么好处？
发布网友
发布时间：2022-10-08 04:27
共5个回答
热心网友
时间：2023-11-25 14:42
首先我们先知道spring的项目分层：
按照MVC的设计理念来讲，由service服务层调用持久层，在由controller调用service，这符合MVC的分层结构也符合我们的编程习惯。
一般是做封装，service做业务，controller校验数据
要是controller直接调用的话，controller直接拿到数据这是不安全的，而且平常的一些业务逻辑处理不好处理，因为业务需求是实时改变的，把业务写在里还要全部更改业务信息，这样不仅不会节约成本还增加耦合，代码复用性也不高后期代码维护也困难。建议还是遵循MVC分层结构开发，尽管是少量数据也不建议直接调用。关于好处可以上别人博客借阅：网页链接
热心网友
时间：2023-11-25 14:42
service层又叫做业务层,本来组织sql之类的都是在这层写,但是很多人会写在层,其实是不对的,但是也没人会在意,而且直接写在层会看起来简单,实则从长久看会麻烦,但是谁会在意呢,这只是个注重效率的时代,service层的目的是重用,就比如你要分页查询,就会分为3个方法,查list,查数量,和一个把这两个组装的方法,这样分页的时候直接调用组装这个方法就可以了,其他地方要查list或者数量就可以调另外的方法,要是把这个都现在一个中那就只专用于查询这个分页了,所以从长久来说在service层写sql是很有必要的(但是时间有时候不能让你思考那么多),再有一个就是service是受数据库事务控制的,就比如你一个请求要改变两个表的数据,那在service层调用两次就可以了,如果在controller调用两次service那第一次成功第二次失败了是不是还要回滚第一次的改变?
controller 主要是处理一些不想关业务的逻辑,就比如你人员表中存的人员所属部门的id,你现在不可能把id直接显示到页面上,但是又想少些sql和少的代码,那你就可以差分页之后,再在controller中调用查部门的service,这样把分页查到的list遍历一下就可以把按id把部门插进去,这样的好处是你人员的查询service中的sql只关心人员表的数据,不用各种关联其它表(但是有时候还是需要关联的).
就说这么多吧,纯手打,第一次打这么多东西....
热心网友
时间：2023-11-25 14:43
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层和其他层次耦合很低，完全可以单独开发。
热心网友
时间：2023-11-25 14:43
跳来跳去的我脑子都晕啦。。。
这就是为什么有人会把所有的东西都扔在一个层里，比如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个维度，按层拆，按模块拆。
将拆好的不同项目分别部署在不同的服务器上，并且再分不同的小集群。
第三个阶段（分布式服务架构）：
唉呀妈呀，访问量陡增，到这步你创业应该算成功了，开始烧投资人的钱了吧。
经过上面拆成了越来越多的模块，模块与模块交互越来越多，怎么办？
这个时候我们需要把核心的业务抽出来，作为独立的服务，慢慢发展成稳定的服务中心，
用来提升业务复用和整合。
就像阿里的大牛说过，没有淘宝的积累，天猫能那么快的出来吗？
这个时候，你的缓存，数据库，消息队列等服务都应该是分布式的。
第四个阶段（流动计算架构）
哎呀妈呀，访问量又上了一个台阶，翻了好几百倍吖，肿么办？
这个时候服务越来越多，一些容量和资源的浪费问题凸显出来，
这时我们需要一个调度中心来基于访问压力动态的管理集群容量，
提高利用率。
第五个阶段（云计算架构）
抱歉，作者正在学习分布式架构中，未完待续。
热心网友
时间：2023-11-25 14:44
spring mvc 里面的 mvc 是有其意义的。
mvc全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写。是一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
可能你注意到了，这里面并没有service，因为mvc概念也是从桌面软件开发中移植过来的，所以在应用到网络应用开发中，进行了一些改变，service层就是新演变出来的， service负责业务逻辑处理，如果没有service层，那要把业务代码放到controller中，一些公共的方法就无法实现共享，总的来说，service的出现就是为了代码重用。
至于是属于模型层的，也是一样受用于分层的概念，分层的优势有两个：解耦代码、实现重用。
MVC只是一种设计规范，不是硬性的，比如：如果项目很小，那可以没有service。
