Spring MVC AbstractController

赠人玫瑰,手留余香.人生最大的快乐不在于占有什么而在于追求什么的过程.

推荐文章：http://jinnianshilongnian.iteye.com/blog/1608234

Controller

Controller是Spring MVC框架支持的用于处理具体Web请求的handler类型之一。在使用Spring MVC框架开发Web应用程序过程中，它是我们接触最多的角色，几乎每个请求流程的实现都需要与Controller打交道（否则具体的处理逻辑写到哪里去呢？），所以称其为“亲密伙伴”也不为过吧！

要实现一个具体的Controller，我们当然可以直接实现Controller接口，其定义如下：
 
public interface Controller {
    ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse ➥
    response) throws Exception;
}
 

但更多时候，我们可能会寻求使用Spring MVC提供的更细粒度的Controller框架类。直接实现Controller接口当然没有问题，这让我们可以随心所欲地实现Web处理过程中的所有关注点，但这通常需要我们关注更多底层的细节，比如请求参数的抽取、请求编码的设定、国际化信息的处理、Session数据的管理等。而实际上，可能这些细节或者关注点是所有的Controller都需要的。我们就应该想办法让这些通用的逻辑可以以某种方式被复用。这也就是Spring MVC提供了一套Controller实现体系的原因。它帮助我们更好地处理了Web请求处理过程中的某些通用关注点。图24-3给出了Spring MVC中Controller的继承层次体系的概况。

为了便于理解，我们不妨把Controller划分为如下两类。

• 自由挥洒派的Controller。之所以将AbstractController和MultiActionController归为自由挥洒一派，是因为基本上只要你熟悉Servlet API，就可以随意处理Web请求了。如果你是从Servlet时代走过来的，那么会发现这一派的做事风格让你觉得很亲切，从HttpServ- letRequest中获取参数，然后验证，调用业务层逻辑，最终返回一个ModelAndView，甚至，你都可以直接通过HttpServletResponse输出最终的视图。不过自由倒是自由了，杂七杂八要处理的细节也很多，所以，使用AbstractController和MultiActionController之前最好先考察一下当前场景是否合适。如果要处理的底层细节过多，那么不妨求助一下“规范操作派”的各位仁兄！
• 规范操作派的Controller。以BaseCommandController为首的规范操作一派，对Web处理过程中的某些通用逻辑做了进一步的规范化封装处理，规范化的方面主要包括：
  1. 自动抽取请求参数并绑定到指定的Command对象[1]；
  2. 提供了统一的数据验证方式，BaseCommandController及其子类可以接收一组org.springframework.validation.Validator以进行数据验证，我们可以根据具体数据提供相应的Validator实现；
     

  3. 规范化了表单（Form）请求的处理流程，并且对简单的多页面表单请求处理提供支持。

     虽然这套“制度”对我们的自由挥洒进行了限定，但只要我们熟悉了这套规则，依然可以游刃于其间。

各门派我们已经介绍完了，下面是各派中实力比较雄厚的诸位弟子的表演时间……

AbstractController

AbstractController是整个Controller继承层次的起源（多少有点儿少林正宗弟子的意味），该类通过模板方法模式（Template Method Pattern）帮我们解决了如下几个通用关注点：

• 管理当前Controller所支持的请求方法类型（GET/POST）；
• 管理页面的缓存设置，即是否允许浏览器缓存当前页面；
• 管理执行流程在会话（Session）上的同步。

而我们所要做的，只不过是在AbstractController所公开的handleRequestInternal (request,response)模板方法中实现具体Web请求处理过程中的其他逻辑。

说明
supportMethods	表明控制器会接收哪些方法。一般会默认设置GET 和POST ，你也可以修改这些方法。如果一个请求携带的方法是这个控制器不支持的，客户端会被告知，抛出ServletException 。
requireSession	表明控制器是否需要HTTP session 。
synchronizeOnSession	确定是否对HTTP session 实行同步。
cacheSeconds	设置cache 时间。默认是-1 ，则不设置。
useExpiresHeader	为了与HTTP1.0 的‘Expires’ 兼容. 默认true
useCacheHeader	为了与HTTP1.0 的‘Cache-Control’ 兼容，默认true

继承WebContentGenerator
用于提供如浏览器缓存控制、是否必须有session开启、支持的请求方法类型（GET、POST等）等，该类主要有如下属性：
 
Set<String>   supportedMethods：设置支持的请求方法类型，默认支持“GET”、“POST”、“HEAD”，如果我们想支持“PUT”，则可以加入该集合“PUT”。
boolean requireSession = false：是否当前请求必须有session，如果此属性为true，但当前请求没有打开session将抛出HttpSessionRequiredException异常；
 
boolean useExpiresHeader = true：是否使用HTTP1.0协议过期响应头：如果true则会在响应头添加：“Expires：”；需要配合cacheSeconds使用；
 
boolean useCacheControlHeader = true：是否使用HTTP1.1协议的缓存控制响应头，如果true则会在响应头添加；需要配合cacheSeconds使用；
 
boolean useCacheControlNoStore = true：是否使用HTTP 1.1协议的缓存控制响应头，如果true则会在响应头添加；需要配合cacheSeconds使用；
 
private int cacheSeconds = -1：缓存过期时间，正数表示需要缓存，负数表示不做任何事情（也就是说保留上次的缓存设置），
      1、cacheSeconds =0时，则将设置如下响应头数据：
        Pragma：no-cache             // HTTP 1.0的不缓存响应头
        Expires：1L                  // useExpiresHeader=true时，HTTP 1.0
        Cache-Control ：no-cache      // useCacheControlHeader=true时，HTTP 1.1
        Cache-Control ：no-store       // useCacheControlNoStore=true时，该设置是防止Firefox缓存
 
      2、cacheSeconds>0时，则将设置如下响应头数据：
        Expires：System.currentTimeMillis() + cacheSeconds * 1000L    // useExpiresHeader=true时，HTTP 1.0
        Cache-Control ：max-age=cacheSeconds                    // useCacheControlHeader=true时，HTTP 1.1
 
      3、cacheSeconds<0时，则什么都不设置，即保留上次的缓存设置。
 
 
此处简单说一下以上响应头的作用，缓存控制已超出本书内容：
HTTP1.0缓存控制响应头
  Pragma：no-cache：表示防止客户端缓存，需要强制从服务器获取最新的数据；
  Expires：HTTP1.0响应头，本地副本缓存过期时间，如果客户端发现缓存文件没有过期则不发送请求，HTTP的日期时间必须是格林威治时间（GMT）， 如“Expires:Wed, 14 Mar 2012 09:38:32 GMT”；
 
HTTP1.1缓存控制响应头
  Cache-Control ：no-cache       强制客户端每次请求获取服务器的最新版本，不经过本地缓存的副本验证；
  Cache-Control ：no-store       强制客户端不保存请求的副本，该设置是防止Firefox缓存
  Cache-Control：max-age=[秒]    客户端副本缓存的最长时间，类似于HTTP1.0的Expires，只是此处是基于请求的相对时间间隔来计算，而非绝对时间。
 
 还有相关缓存控制机制如Last-Modified（最后修改时间验证，客户端的上一次请求时间 在 服务器的最后修改时间 之后，说明服务器数据没有发生变化 返回304状态码）、ETag（没有变化时不重新下载数据，返回304）。