Spring MVC中的M V C

M→Model 模型

V→View 视图

C→Controller 控制器

也就是说一次交互由生到死(请求到相应) 需要经过这三个层级来完成那么为什么这么设计这么设计又有什么好处我是这么认为的

首先Model指的是什么是业务处理的数据参数业务处理之后数据返回的数据结果

什么又是视图呢? 对于编程人员来讲我想从一个网站得到我想要得到的数据内容即使在空白的页面上面显示出来一段Json串我们也是可以得到我们想要的信息的那么这种只有Json串的空白页面到底属不属于View视图我的理解是属于的我的认知是凡是可以展现出数据结果的都可以称为视图

控制器又是什么呢? 服务器接收到请求根据请求的参数决定调用哪个模型去处理业务需求，然后再确定用哪个视图来渲染这次请求的结果

PS:由于 JSP的各种缺点编译速度慢(首先被转换为 .java文件(Servlet) 然后将.java文件编译为字节码文件) 不好进行调试等一系列缺点再加上前段三大框架 VUE React Angular 再加上前后端分离并行开发所带来的优势在视图渲染这块我们只需要将数据按照约定好的模型返回给浏览器交给前段同事处理即可

MVC 中的请求处理工作流程

1.从流程图里面我们可以看出在MVC中每一层都是独立的自己解决自己所负责的功能当用户用浏览器发出请求的时候我们首当其冲的是接受用户请求的参数 (请求体请求头等等..) 再由DispatcherServlet(中央处理器) 来决定分发到哪一个具体的控制器我会在以后的文章具体讲解一下DispatcherServlet 到了这里我们的控制器工作基本完成也就是说请求到了服务器控制器控制请求以具体分发到哪一个具体的控制器我们可以看到每一个请求都需要经过DispatcherServlet 可想而知他的重要性

2.既然已经到了控制器我们也拿到了请求参数那么下一步我们就需要进行具体的业务处理也就是Modal 看到Modal(模型) 可能很多人都觉得他应该就是返回给前端的数据模型我一开始也是这么认为的但是在我仔细的看了Spring官网的时候我发现数据本身在设计模式里并不算什么他可能是一个你封装的一个实体类一段JSON字符串一个数字但我们真正需要的注意的是这些数据是从哪里来的我们拿到用户的参数是一定需要进行业务处理的他可能需要交互自己的数据可能需要调用他人接口而这些真正处理请求参数并得到结果的我们统称为Modal

3.此时我们用'C'接到了用户参数到了控制器由经过了'M'进行了数据的业务处理得到了用户想要的数据省下来就应该返回视图(页面)呈现给用户让用户得到自己想要的信息也就是我们的'V' 一个项目中我们往往有很多页面具体返回到哪一个页面进行渲染这也是通过我们之前提到过的DispatcherServlet来决定的这样子我们一次请求到响应的流程也就全部结束了

总结:之所以使用MVC这种模式是因为可以把一次请求到响应可以分成三层这三层之间解耦各司其职多一层冗余少一层无法解决

这也牢牢地遵守的设计模式中的

开闭原则