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这种模式 是因为可以把一次请求到响应 可以分成三层 这三层之间解耦 各司其职 多一层冗余 少一层无法解决

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