标签：控制器 请求 Spring 视图 MVC JSP 体系结构
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
标签：控制器,请求,Spring,视图,MVC,JSP,体系结构 来源： https://blog.51cto.com/aeolian/2853207
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。