Spring MVC体系结构
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
![微信公众号二维码](https://images.cnblogs.com/cnblogs_com/aeolian/1679458/o_wechat_gzh_qrcode.jpg)