MVC设计模式
在传统的Web应用开发中，架构模式基本一致：
- 数据实体：POJO
- 数据层：DAO
- 业务层：Service
- 控制层：Servlet
- 表示层（页面层）：JSP页面或HTML页面
这种架构模式就是MVC设计模式，它是软件工程中的一种架构模式，强制性地使软件系统的输入、处理和输出分开，把系统分为三个基本部分：模型(Model)、视图(View)、控制器（Controller）
MVC模式中各部分的职责
Model：模型对象拥有最多的处理任务，是应用程序的主体部分，它负责数据逻辑（业务逻辑）的处理和实现数据库的操作。在项目中除了控制层的控制器，几乎每一个Bean组件都属于模型，比如Service层、DAO层，以及POJO实体类等。
View：负责格式化数据并把它们呈现给用户，包括数据展示、用户交互、数据验证、页面设计等功能。说白了就是离用户最近的、展示给人们看的，比如HTML或者JSP页面。
Controller：负责接收并转发请求，对请求处理之后拿到响应结果，指派要使用的视图（类似于指定Servlet跳转到不同的页面进行展示），将响应结果返回给客户端。对应的组件一般是Servlet，很少用JSP页面直接处理其他页面过来的请求。
JSP Model1
JSP+JavaBean
在一个项目中，如果业务流程比较简单的时候，可以把控制器的功能交给视图，项目架构中只有视图和模型，没有控制器。
Model1模式的基础是JSP，它由JSP和JavaBean组成，JSP从HTTPRequest中获取所需要的数据，并调用JavaBean进行业务逻辑的处理，然后通过HTTPResponse将结果返回给前端浏览器。可见，Model1一定程度上实现了MVC，只不过将控制层和视图层统一定位到JSP页面，JavaBean依然充当模型组件。这种模式下JSP身兼多职，既要负责视图层的数据展示，又要负责业务流程控制，结构较为混乱，也不是我们所希望的松耦合架构，所以在大型项目中或者当业务流程比较复杂的时候不建议这样做。
JSP Model2
JSP+Servlet+JavaBean
当业务流程比较复杂的时候，就需要把业务流程控制交给专门的控制器，JSP只专注于视图的渲染展现即可。这种模式就是JSP Model2，即JSP+Servlet+JavaBean，也就是典型的MVC设计模式。
相比于Model1，Model2是将控制层单独划分出来，以Servlet的形式存在于项目架构中，负责业务流程的控制，接收请求，创建所需的JavaBean组件，并将处理后的数据返回给视图（JSP/HTML）进行结果渲染展示。这样的结构比较清晰，效果明显优化很多，并且结合Spring的IoC和AOP，也是一个松耦合的架构模式。所以，除非项目特别简单，一般情况下推荐使用JSP Model2。
MVC处理流程及优缺点
通过以上对MVC的了解，我们不妨分析一下MVC的处理过程：
首先视图提供系统与用户交互的界面，并发送用户的输入给控制器；
控制器接收到用户的请求，根据判断，决定调用哪个模型的哪个方法进行处理；
模型被控制器调用，根据控制器的指令进行相应的业务逻辑处理，并返回处理结果（数据）；
控制器根据返回的结果，调用相应的视图来渲染、格式化模型返回的数据；
视图响应给客户端浏览器。
以上即是MVC的处理流程以及各部分之间的关系，那么任何一件事都会有利有弊，我们再分析一下MVC模式的优缺点。
优点：
可以多视图共享多个模型，大大提高了代码的复用性；
MVC的三个模块相互独立，松耦合架构；
控制器提高了应用程序的灵活性和可配置性；
有利于项目的管理和维护。
缺点：
原理较复杂，实现起来固然没有JSP+JavaBean的方式来得快；
增加了系统结构和实现的复杂性；
视图对模型数据的访问效率较低。
总之，我们可以通过MVC的设计模式，最终打造出一个松耦合+高复用+高适用性等的完美架构，这也是架构设计的目标之一。但是，对于MVC来说，它并不适用于小型的项目，花费大量的时间将MVC应用到项目中通常得不偿失，夸张点说，可能搭建三层架构、构建MVC开发环境的时间，都可以实现整个项目功能了。所以，是否使用MVC模式，应该根据实际场景来决定。
Spring MVC
springmvc框架的请求处理流程
Spring MVC也是一个基于请求驱动的Web框架，并且也使用了前端控制器模式来进行设计，再根据请求映射规则分发给相应的页面控制器（处理器）来进行处理，下面具体分析一下它的处理步骤：
首先用户发送请求到前端控制器（DispatcherServlet），前端控制器根据请求信息（比如URL）决定将请求分发给哪个页面控制器（Controller）来处理。对应上图中的步骤1、2。
页面控制器接收到请求之后，进行业务处理，处理完毕之后返回一个ModelAndView。对应上图中的步骤3、4、5。
前端控制器将控制权收回，然后根据返回的逻辑视图名，通过视图解析器选择真正的视图，将模型数据传入供其渲染展示。对应上图中的步骤6、7。
前端控制器再次收回控制权，将响应结果返回给浏览器客户端，至此整个流程结束。对应上图中的步骤8。
Spring MVC框架的体系结构
客户端发出HTTP请求，Web应用服务器接收此请求。如匹配DispatcherServlet的请求映射路径，则Web容器将该请求转交给DispatcherServlet处理；
DispatcherServlet拿到请求之后，根据请求的信息（URL、请求参数、HTTP方法等）及HandlerMapping的配置找到处理请求的处理器（Handler）；
当DispatcherServlet找到相应的Handler之后，通过HandlerAdapter对Handler进行封装，再以统一的适配器接口调用Handler。HandlerAdapter可以理解为真正使用Handler来干活的人。
在请求信息真正到达调用Handler的处理方法之前的这段时间，Spring MVC还完成了很多工作，它会将请求信息以一定的方式转换并绑定到请求方法的入参，对于入参的对象会进行数据转换、数据格式化以及数据校验等。这些都做完以后，最后才真正调用Handler的处理方法进行相应的业务逻辑处理。
处理器完成业务处理之后，将一个ModelAndView对象返回给DispatcherServlet，其中包含了逻辑视图名和模型数据信息。
DispatcherServlet通过ViewResolver将逻辑视图名解析为真正的视图对象View，可以是JSP、HTML、XML、PDF、JSON等等，Spring MVC均可灵活配置，在以后会介绍。
得到真正的视图对象之后，DispatcherServlet会根据ModelAndView对象中的模型数据对View进行视图渲染。
最终客户端获得响应消息。
Spring MVC框架的特点
- 角色划分清晰。Model、View、Controller各司其职，耦合度较低。
- 灵活的配置功能。Spring的核心是IoC和AOP，统一可以实现在MVC上，把各种类当作Bean组件配置在Spring容器中。
- 提供了大量的接口和实现类，方便各种场景的开发。
- 真正做到与View层的实现无关。
- 结合Spring的依赖注入，更好地应用了面向接口编程的思想。
- 可以与Spring天衣无缝的整合
Spring MVC需要的jar包
参考：
https://blog.csdn.net/wzy18210825916/article/details/82799764