第四章 Controller接口控制器详解

4.1、Controller简介

Controller控制器，是MVC中的部分C，为什么是部分呢？因为此处的控制器主要负责功能处理部分：

1、收集、验证请求参数并绑定到命令对象；

2、将命令对象交给业务对象，由业务对象处理并返回模型数据；

3、返回ModelAndView（Model部分是业务对象返回的模型数据，视图部分为逻辑视图名）。

还记得DispatcherServlet吗？主要负责整体的控制流程的调度部分：

1、负责将请求委托给控制器进行处理；

2、根据控制器返回的逻辑视图名选择具体的视图进行渲染（并把模型数据传入）。

因此MVC中完整的C（包含控制逻辑+功能处理）由（DispatcherServlet + Controller）组成。

因此此处的控制器是Web MVC中部分，也可以称为页面控制器、动作、处理器。

Spring Web MVC支持多种类型的控制器，比如实现Controller接口，从Spring2.5开始支持注解方式的控制器（如@Controller、@RequestMapping、@RequestParam、@ModelAttribute等），我们也可以自己实现相应的控制器（只需要定义相应的HandlerMapping和HandlerAdapter即可）。

4.2、Controller接口

package org.springframework.web.servlet.mvc;
public interface Controller {
       ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception;
}

       这是控制器接口，此处只有一个方法handleRequest，用于进行请求的功能处理，处理完请求后返回ModelAndView（Model模型数据部分 和 View视图部分）。

     Spring默认提供了一些Controller接口的实现以方便我们使用，具体继承体系如图4-1：

4.3、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）。

该抽象类默认被AbstractController和WebContentInterceptor继承。

4.4、AbstractController

该抽象类实现了Controller，并继承了WebContentGenerator（具有该类的特性，具体请看4.3），该类有如下属性：

boolean synchronizeOnSession = false：表示该控制器是否在执行时同步session，从而保证该会话的用户串行访问该控制器。

public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
              //委托给WebContentGenerator进行缓存控制
              checkAndPrepare(request, response, this instanceof LastModified);
              //当前会话是否应串行化访问.
              if (this.synchronizeOnSession) {
                     HttpSession session = request.getSession(false);
                     if (session != null) {
                            Object mutex = WebUtils.getSessionMutex(session);
                            synchronized (mutex) {
                                   return handleRequestInternal(request, response);
                            }
                     }
              }
              return handleRequestInternal(request, response);
}

      可以看出AbstractController实现了一些特殊功能，如继承了WebContentGenerator缓存控制功能，并提供了可选的会话的串行化访问功能。而且提供了handleRequestInternal方法，因此我们应该在具体的控制器类中实现handleRequestInternal方法，而不再是handleRequest。

4.5、ServletForwardingController

将接收到的请求转发到一个命名的servlet

4.6、BaseCommandController

命令控制器通用基类，提供了以下功能支持：

1、数据绑定：请求参数绑定到一个command object（命令对象，非GoF里的命令设计模式），这里的命令对象是指绑定请求参数的任何POJO对象；

   commandClass：表示命令对象实现类，如UserModel；

   commandName：表示放入请求的命令对象名字（默认command），request.setAttribute(commandName, commandObject);

2、验证功能：提供Validator注册功能，注册的验证器会验证命令对象属性数据是否合法；

   validators：通过该属性注入验证器，验证器用来验证命令对象属性是否合法；

该抽象类没有没有提供流程功能，只是提供了一些公共的功能，实际使用时需要使用它的子类。

4.7、AbstractCommandController

命令控制器之一，可以实现该控制器来创建命令控制器，该控制器能把自动封装请求参数到一个命令对象，而且提供了验证功能。

4.8、AbstractFormController

用于支持带步骤的表单提交的命令控制器基类，使用该控制器可以完成：

1、定义表单处理（表单的渲染），并从控制器获取命令对象构建表单；

2、提交表单处理，当用户提交表单内容后，AbstractFormController可以将用户请求的数据绑定到命令对象，并可以验证表单内容、对命令对象进行处理。

  bindOnNewForm：是否在进行表单展示时绑定请求参数到表单对象，默认false，不绑定；

    sessionForm：session表单模式，如果开启（true）则会将表单对象放置到session中，从而可以跨越多次请求保证数据不丢失（多步骤表单常使用该方式，详解AbstractWizardFormController），默认false；

    Object formBackingObject(HttpServletRequest request) ：提供给表单展示时使用的表单对象（form object表单要展示的默认数据），默认通过commandName暴露到请求给展示表单；

    Map referenceData(HttpServletRequest request, Object command, Errors errors)：展示表单时需要的一些引用数据（比如用户注册，可能需要选择工作地点，这些数据可以通过该方法提供）

SimpleFormController继承该类，而且提供了更简单的表单流程控制。

4.9、SimpleFormController

提供了更好的两步表单支持：

1、准备要展示的数据，并到表单展示页面；

2、提交数据数据进行处理。

第一步，展示：

第二步，提交表单：

4.10、CancellableFormController

一个可取消的表单控制器，继承SimpleFormController，额外提供取消表单功能。

1、表单展示：和SimpleFormController一样；

2、表单取消：和SimpleFormController一样；

3、表单成功提交：取消功能处理方法为：onCancel(Object command)，而且默认返回cancelView属性指定的逻辑视图名

         那如何判断是取消呢？如果请求中有参数名为“_cancel”的参数，则表示表单取消。也可以通过cancelParamKey来修改参数名（如“_cancel.x”等）。

4.11、AbstractWizardFormController

向导控制器类提供了多步骤（向导）表单的支持（如完善个人资料时分步骤填写基本信息、工作信息、学校信息等）

假设现在做一个完善个人信息的功能，分三个页面展示：

1、页面1完善基本信息；

2、页面2完善学校信息；

3、页面3完善工作信息。

这里我们要注意的是当用户跳转到页面2时页面1的信息是需要保存起来的，还记得AbstractFormController中的sessionForm吗？ 如果为true则表单数据存放到session中，哈哈，AbstractWizardFormController就是使用了这个特性。

向导中的页码从0开始；

4.12、ParameterizableViewController

参数化视图控制器，不进行功能处理（即静态视图），根据参数的逻辑视图名直接选择需要展示的视图。 

该控制器接收到请求后直接选择参数化的视图，这样的好处是在配置文件中配置，从而避免程序的硬编码，比如像帮助页面等不需要进行功能处理，因此直接使用该控制器映射到视图。

4.13、AbstractUrlViewController

提供根据请求URL路径直接转化为逻辑视图名的支持基类，即不需要功能处理，直接根据URL计算出逻辑视图名，并选择具体视图进行展示：

urlDecode：是否进行url解码，不指定则默认使用服务器编码进行解码（如Tomcat默认ISO-8859-1）；

urlPathHelper：用于解析请求路径的工具类，默认为org.springframework.web.util.UrlPathHelper。

UrlFilenameViewController是它的一个实现者，因此我们应该使用UrlFilenameViewController。

4.14、UrlFilenameViewController

将请求的URL路径转换为逻辑视图名并返回的转换控制器，即不需要功能处理，直接根据URL计算出逻辑视图名，并选择具体视图进行展示