Controller接口控制器详解

Posted 2021-01-02 yuexiaoyun

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即可）。

 

因为考虑到还有部分公司使用继承Controller接口实现方式，因此我们也学习一下，虽然已经不推荐使用了。

 

对于注解方式的控制器，后边会详细讲，在此我们先学习Spring2.5以前的Controller接口实现方式。

 

首先我们将项目springmvc-chapter2复制一份改为项目springmvc-chapter4，本章示例将放置在springmvc-chapter4中。

大家需要将项目springmvc-chapter4/ .settings/ org.eclipse.wst.common.component下的chapter2改为chapter4，否则上下文还是“springmvc-chapter2”。以后的每一个章节都需要这么做。

 

4.2、Controller接口

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

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

 

 

 

 

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继承。