（spring-第21回【MVC基础篇】）SpringMVC一点就通

概述

• Spring MVC通过一套MVC注解，让POJO变成处理请求的控制器，无需实现任何接口，同时，SpringMVC还支持REST风格的URL请求：注解驱动和REST风格的Spring MVC是Spring 3.0最出彩的功能之一。
• Spring MVC框架围绕 DispatcherServlet这个核心展开，DispatcherServlet是SpringMVC的总导演，它负责截获请求，并将其分派给相应的处理器处理。
• 和大多数WEB MVC一样，Spring MVC通过一个前端Servlet接收所有的请求，并将具体工作委托给其他组件进行处理，DispatcherServlet就是Spring MVC的前端Servlet。

本文主要讲了一些什么

 

Spring MVC的基本原理  -->

用一个简单的示例对基本原理有个具体了解 -->

分别描述MVC的几个重量级角色：过滤请求、绑定请求、封装对象、处理XML和JSON、处理模型数据。

 

本篇文章重在知识点整合，作为读书笔记，语言简洁，删繁就简，由浅入深，引人入胜。通读本文，你将对Spring MVC有一个深入的了解。如果读，请深读。如果爱，请读完。

 

基本原理

要了解Spring MVC框架的工作机理，必须回答下面三个问题:

问题一：DispatcherServlet框架如何截获特定的HTTP请求，交由Spring MVC框架处理？

答：在web.xml中配置一个Servlet，并通过<servlet-mapping>指定其处理的url。像下面这样：

那么，所有带.html后缀的http请求都会被DispatcherServlet截获并处理。

问题二：位于Web层的Spring容器（WebApplicationContext）如何与位于业务层的Spring容器（ApplicationContext）相关联，以使web层的bean可以调用业务层的bean？

答：下面是一个web.xml:

ContextLoaderListener是一个ServletContextListener，它通过contextConfigLocation参数指定的配置文件（如本例的applicationContext.xml）启动“业务层”的Spring容器。而由下面引入的DispatcherServlet启动Web层的spring容器。Web层的spring容器将作为业务层容器的子容器（即：Web层容器可以引用业务层容器的bean，而业务层容器不可以引用Web层容器的bean。）

问题三：如何初始化Spring MVC的各个组件，并将它们装配到DispatcherServlet中？

答：当DispatcherServlet加载后，就会自动扫描上下文的bean，根据名称或者类型匹配的机制查找自定义的组件，找不到时则使用DispatcherServlet.properties中使用的默认组件。

 

一个简单的实例

 

Spring MVC的开发一般包括以下步骤：

步骤一 ：配置web.xml,指定业务层对应的配置文件，定义DispatcherServlet：

步骤二：编写处理请求的控制器（处理器）：

@Controller注解将一个POJO类转化为处理请求的控制器，通过@RequestMapping指定控制器处理哪些请求。上例中，处理/user/register请求，返回user/register视图（当然，该视图字符串加上前后缀才能定位到具体JSP，后面步骤会讲到）。

步骤三：编写视图对象（比如JSP）：

步骤四：配置Spring MVC的配置文件（如applicationContext.xml）：

1是默认的视图解析器，2是视图解析器加的前后缀，它与步骤二返回的user/register拼起来：/WEB-INF/views/user/register.jsp，表示步骤二将返回这个视图，即：把请求交给这个jsp来处理。

 

过滤请求

使用@RequestMapping可以过滤请求URL、请求参数、请求方法，请求头这4个方面的信息项。比如：

 

 

绑定请求信息到方法入参中

Spring MVC会将HTTP请求的信息绑定到相应的方法入参中，并根据方法返回值类型作出相应的后续处理。比如：

 

 

将请求信息封装成对象

使用HttpMessageConverter<T>可以将请求信息转换成一个对象，或者将对象输出为响应信息。（T就是对象类型）。

两把利剑：

1.使用RequestBody、ResponseBody。

2.使用HttpEntity<T>/ResponseEntity<T>

示例1：

客户端：

服务端：

 

示例2：

客户端：

 

服务端：

 

与RequestBody、ResponseBody不同的是，HttpEntity不仅可以访问请求、响应报文体的数据，还可以访问请求和响应报文头的数据。

示例1：

客户端：

 

服务端：

 

示例2：

客户端：

服务端：

怎么做到的？

 

HttpMessageConverter<T>提供了众多的实现类，它组成了一个功能强大、用途广泛的HttpMessageConverter<T>家族。

 

比如：

 

　　StringHttpMessageConverter负责将请求信息转换成字符串；

 

　　FormHttpMessageConverter负责将表单数据读取到MultiValueMap中；

 

　　还有诸如读写XML、Resource、JSON等等对应的实现类。

 

　　AnnotationMethodHandlerAdapter适配器默认装配了基本的Converter（String、ByteArray、Source、XmlAwareForm），容器会根据需要自动调用不同的HttpMessageConverter实现类。

　　如果不能满足需求，那么继续在xml中配置其他的converter：

 

 

处理XML和JSON

 

从上文可知，HttpMessageConverter有一个很强大的家族，能够处理各种格式的请求及响应。当然也可以处理XML和JSON。

 

处理XML和JSON的Converter分别是：

 

MarsHallingHttpMessageConverter(处理xml)。

 

Jaxb2RootElementHttpMessageConverter(同上，底层使用JAXB)。

 

MappingJacksonHttpMessageConverter（处理JSON）。

 

按照前文的思路，首先要在配置文件中装配好相应的Converter，但是还有其他必要的步骤：

步骤1：XML中配置Converter以及Marshaller:

步骤2：测试客户端发出请求：

步骤3：响应（服务）端：

步骤4：User的注解：

步骤5：用tcptrace监听测试

其实，如果把第92行和第93行代码的头部格式换成json，就变成传送json格式的数据了。这个时候，用tcptrace监听传送json的结果：

可以看到，请求中，我们的报文头格式变成了json，报文体也是json格式的。而响应中报文体也是json格式的。

为什么我直接截图了json格式的测试结果而没有测试请求xml的测试结果呢?

因为在xml测试时，报出了415 Unsupported media type的错误，尚未发现原因。

但是思路就是这样了。 读者如果知道“不支持此类型”的原因，欢迎评论留言。

 

 

处理模型数据

 

 

我们在Controller控制器中接收请求参数，把处理后得到的数据封装起来，然后返回到一个JSP，在JSP中就可以获取封装的数据。那么，在这个例子中，封装的数据就是模型数据，而JSP就是渲染模型数据的视图。这在MVC框架中是最重要的步骤。

在控制器方法中输出模型数据有四种方法：

方法一：ModelAndView

在控制器方法中新建ModelAndView对象，把“视图”和“模型数据”封装到该对象中，然后返回该对象即可。

方法二：@ModelAttribute

加到入参的前面，就自动把入参绑定为模型数据；加到方法A的前面，那么Spring MVC就会在执行任何目标处理方法之前，先执行方法A(B\C等等)，然后把这些加了标注的方法的返回值绑定为模型数据。

举例1：

Spring MVC会先把模型数据储存到ServletRequest的属性列表中（使用setAttribute保存）。

然后在返回的jsp（视图对象）中，使用${user.userName}来访问user的属性。

举例2：

在执行handle62之前，spring扫描到有方法头部标注了@ModelAttribute，那么，spring就会先去执行getUser，并把返回值user作为模型数据，键为”user”。

这时执行handle62，入参前面的@ModelAttribute键为”user”，正好匹配了刚封装的模型数据的键，那么就把模型数据赋值给入参User user，然后285行对user做了覆盖操作，最后交给视图层处理。

方法三：Map and Model

如果处理方法的入参类型为Map或者Model（或者具备二者功能的对象如：ModelMap），那么spring会将隐含的模型数据传给该入参，在处理方法中，我们可以从该入参中取出隐含的模型数据，也可以继续添加模型数据。

标注了@ModelAttribute的方法的返回值（getUser方法返回的user）就是隐含的模型数据。

由于handle63的入参为ModelMap类型，所以，spring会把user这个隐含模型数据授予modelMap，在300行，我们通过该入参取出模型数据，在302行，我们通过该入参继续添加模型数据。

方法四：@SessionAttributes

如果Controller类的头部标注了@SessionAttributes（”xxx”）,那么spring会把键为xxx的模型数据暂存到HttpSession中，以便多个请求之间可以共享该数据。

 

... ...

61行的标注表示：后面处理器在处理任何方法时，看到属性名为user的模型属性就会把它存到session中共享。由于328行把user作为了模型数据，那么这个user就放到了session中。

当转发请求到handle72时，就可以从modelMap中拿到该对象。

当使用完成时，在338行表示把该对象从session中移除。否则它会一直存在。

然而程序是跑不起来的，会报HttpSessionRequiredException。为什么呢？

这是因为，如果有了61行标注的会话属性user，那么spring就会尝试从会话中获取该属性，然后把它赋给入参。

也就是说，spring看到61行的标注，会从会话中找user为键的模型数据，找到后把它赋值给334行的modelMap。

但是现在从代码看来，在执行61行标注之前，会话中并没有键为user的模型数据。

所以，解决方法很简单：

只需要像方法二那样，加一个：

 

就好了。这样，在执行61行之前，先执行getUser，把user作为隐含模型数据。那么执行61行时，该会话中就已经有user了。

当你读到这里，你已经百毒不侵了。亲，不点个赞吗？