（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有一个深入的了解。如果读，请深读。如果爱，请读完。
基本原理
基本原理及入门示例已在微信订阅号上发布，为防止原创性的冲突检测，故删去这一部分，详情扫码关注查看：
过滤请求
使用@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了。
当你读到这里，你已经百毒不侵了。亲，不点个赞吗？
