第四章 Controller接口控制器詳解（1）——跟著開濤學SpringMVC · 跟我學 Spring 系列

# 第四章 Controller接口控制器詳解（1）——跟著開濤學SpringMVC ## 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視圖部分）。還記得第二章的HelloWorld嗎？我們的HelloWorldController實現Controller接口，Spring默認提供了一些Controller接口的實現以方便我們使用，具體繼承體系如圖4-1： ![](https://box.kancloud.cn/2016-05-13_5735739046d8d.JPG)? 圖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。 **AbstractController使用方法：** 首先讓我們使用AbstractController來重寫第二章的HelloWorldController： ``` public class HelloWorldController extends AbstractController { @Override protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws Exception { //1、收集參數 //2、綁定參數到命令對象 //3、調用業務對象 //4、選擇下一個頁面 ModelAndView mv = new ModelAndView(); //添加模型數據可以是任意的POJO對象 mv.addObject("message", "Hello World!"); //設置邏輯視圖名，視圖解析器會根據該名字解析到具體的視圖頁面 mv.setViewName("hello"); return mv; } } ``` ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/hello" class="cn.javass.chapter4.web.controller.HelloWorldController"/> ``` 從如上代碼我們可以看出： 1、繼承AbstractController 2、實現handleRequestInternal方法即可。 **直接通過response寫響應** 如果我們想直接在控制器通過response寫出響應呢，以下代碼幫我們闡述： ``` public class HelloWorldWithoutReturnModelAndViewController extends AbstractController { @Override protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws Exception { resp.getWriter().write("Hello World!!"); //如果想直接在該處理器/控制器寫響應可以通過返回null告訴DispatcherServlet自己已經寫出響應了，不需要它進行視圖解析 return null; } } ``` ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloWithoutReturnModelAndView" class="cn.javass.chapter4.web.controller.HelloWorldWithoutReturnModelAndViewController"/> ``` 從如上代碼可以看出如果想直接在控制器寫出響應，只需要通過response寫出，并返回null即可。 **強制請求方法類型：** ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloWithPOST" class="cn.javass.chapter4.web.controller.HelloWorldController"> <property name="supportedMethods" value="POST"></property> </bean> ``` 以上配置表示只支持POST請求，如果是GET請求客戶端將收到“HTTP Status 405 - Request method 'GET' not supported”。比如注冊/登錄可能只允許POST請求。 **當前請求的session前置條件檢查，如果當前請求無session將拋出HttpSessionRequiredException異常：** ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloRequireSession" class="cn.javass.chapter4.web.controller.HelloWorldController"> <property name="requireSession" value="true"/> </bean> ``` ``` 在進入該控制器時，一定要有session存在，否則拋出HttpSessionRequiredException異常。 ``` **Session同步：** 即同一會話只能串行訪問該控制器。 **客戶端端緩存控制：** **1、緩存5秒，cacheSeconds=5** ``` package cn.javass.chapter4.web.controller; //省略import public class HelloWorldCacheController extends AbstractController { @Override protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws Exception { //點擊后再次請求當前頁面 resp.getWriter().write("<a href=''>this</a>"); return null; } } ``` ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloCache" class="cn.javass.chapter4.web.controller.HelloWorldCacheController"> <property name="cacheSeconds" value="5"/> </bean> ``` **如上配置表示告訴瀏覽器緩存5秒鐘：** 開啟chrome瀏覽器調試工具： ![](https://box.kancloud.cn/2016-05-13_5735739060239.JPG) 服務器返回的響應頭如下所示： ![](https://box.kancloud.cn/2016-05-15_5737edd540d2f.JPG) 添加了“Expires:Wed, 14 Mar 2012 09:38:32 GMT”?和“Cache-Control:max-age=5”?表示允許客戶端緩存5秒，當你點“this”鏈接時，會發現如下： ![](https://box.kancloud.cn/2016-05-15_5737edd6d7503.JPG) 而且服務器也沒有收到請求，當過了5秒后，你再點“this”鏈接會發現又重新請求服務器下載新數據。 **注：下面提到一些關于緩存控制的一些特殊情況：** 1、對于一般的頁面跳轉（如超鏈接點擊跳轉、通過js調用window.open打開新頁面都是會使用瀏覽器緩存的，在未過期情況下會直接使用瀏覽器緩存的副本，在未過期情況下一次請求也不發送）； 2、對于刷新頁面（如按F5鍵刷新），會再次發送一次請求到服務器的； **2、不緩存，cacheSeconds=0** ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloNoCache" class="cn.javass.chapter4.web.controller.HelloWorldCacheController"> <property name="cacheSeconds" value="0"/> </bean> ``` 以上配置會要求瀏覽器每次都去請求服務器下載最新的數據： ![](https://box.kancloud.cn/2016-05-15_5737edd6eee41.JPG) **3、cacheSeconds<0，將不添加任何數據** 響應頭什么緩存控制信息也不加。 **4、Last-Modified緩存機制** （1、在客戶端第一次輸入url時，服務器端會返回內容和狀態碼200表示請求成功并返回了內容；同時會添加一個“Last-Modified”的響應頭表示此文件在服務器上的最后更新時間，如“Last-Modified:Wed, 14 Mar 2012 10:22:42 GMT”表示最后更新時間為（2012-03-14?10：22）；（2、客戶端第二次請求此URL時，客戶端會向服務器發送請求頭?“If-Modified-Since”，詢問服務器該時間之后當前請求內容是否有被修改過，如“If-Modified-Since: Wed, 14 Mar 2012 10:22:42 GMT”，如果服務器端的內容沒有變化，則自動返回?HTTP 304狀態碼（只要響應頭，內容為空，這樣就節省了網絡帶寬）。 **客戶端強制緩存過期：** （1、可以按ctrl+F5強制刷新（會添加請求頭?HTTP1.0 Pragma:no-cache和?HTTP1.1 Cache-Control:no-cache、If-Modified-Since請求頭被刪除）表示強制獲取服務器內容，不緩存。（2、在請求的url后邊加上時間戳來重新獲取內容，加上時間戳后瀏覽器就認為不是同一份內容： [http://sishuok.com/](http://sishuok.com/)?2343243243?和?[http://sishuok.com/?3433434](http://sishuok.com/?34334343)4?是兩次不同的請求。 **Spring也提供了Last-Modified機制的支持，只需要實現LastModified接口，如下所示：** ``` package cn.javass.chapter4.web.controller; public class HelloWorldLastModifiedCacheController extends AbstractController implements LastModified { private long lastModified; protected ModelAndView handleRequestInternal(HttpServletRequest req, HttpServletResponse resp) throws Exception { //點擊后再次請求當前頁面 resp.getWriter().write("<a href=''>this</a>"); return null; } public long getLastModified(HttpServletRequest request) { if(lastModified == 0L) { //TODO 此處更新的條件：如果內容有更新，應該重新返回內容最新修改的時間戳 lastModified = System.currentTimeMillis(); } return lastModified; } } ``` ``` <!— 在chapter4-servlet.xml配置處理器 --> <bean name="/helloLastModified" class="cn.javass.chapter4.web.controller.HelloWorldLastModifiedCacheController"/> ``` HelloWorldLastModifiedCacheController只需要實現LastModified接口的getLastModified方法，保證當內容發生改變時返回最新的修改時間即可。 **分析：** （1、發送請求到服務器，如（[http://localhost:9080/springmvc-chapter4/helloLastModified](http://localhost:9080/springmvc-chapter3/helloLastModified)），則服務器返回的響應為： ![](https://box.kancloud.cn/2016-05-15_5737edd7159e2.JPG) （2、再次按F5刷新客戶端，返回狀態碼304表示服務器沒有更新過： ![](https://box.kancloud.cn/2016-05-15_5737edd730b5d.JPG) （3、重啟服務器，再次刷新，會看到200狀態碼（因為服務器的lastModified時間變了）。 **Spring判斷是否過期，通過如下代碼，即請求的“If-Modified-Since”?大于等于當前的getLastModified方法的時間戳，則認為沒有修改：** **this.notModified = (ifModifiedSince >= (lastModifiedTimestamp / 1000 * 1000));** **5、ETag（實體標記）緩存機制** （1：瀏覽器第一次請求，服務器在響應時給請求URL標記，并在HTTP響應頭中將其傳送到客戶端，類似服務器端返回的格式：“ETag:"0f8b0c86fe2c0c7a67791e53d660208e3"” （2：瀏覽器第二次請求，客戶端的查詢更新格式是這樣的：“If-None-Match:"0f8b0c86fe2c0c7a67791e53d660208e3"”，如果ETag沒改變，表示內容沒有發生改變，則返回狀態304。 **Spring也提供了對ETag的支持，具體需要在web.xml中配置如下代碼：** ``` <filter> <filter-name>etagFilter</filter-name> <filter-class>org.springframework.web.filter.ShallowEtagHeaderFilter</filter-class> </filter> <filter-mapping> <filter-name>etagFilter</filter-name> <servlet-name>chapter4</servlet-name> </filter-mapping> ``` 此過濾器只過濾到我們DispatcherServlet的請求。 **分析：** 1）：發送請求到服務器：“[http://localhost:9080/springmvc-chapter4/hello](http://localhost:9080/springmvc-chapter3/hello)”，服務器返回的響應頭中添加了（ETag:"0f8b0c86fe2c0c7a67791e53d660208e3"）： ![](https://box.kancloud.cn/2016-05-15_5737edd749860.JPG) 2）：瀏覽器再次發送請求到服務器（按F5刷新），請求頭中添加了“If-None-Match: "0f8b0c86fe2c0c7a67791e53d660208e3"”，響應返回304代碼，表示服務器沒有修改，并且響應頭再次添加了“ETag:"0f8b0c86fe2c0c7a67791e53d660208e3"”（每次都需要計算）： ![](https://box.kancloud.cn/2016-05-15_5737edd75ff2c.JPG) **那服務器端是如何計算ETag的呢？** ``` protected String generateETagHeaderValue(byte[] bytes) { StringBuilder builder = new StringBuilder("\"0"); DigestUtils.appendMd5DigestAsHex(bytes, builder); builder.append('"'); return builder.toString(); } ``` bytes是response要寫回到客戶端的響應體（即響應的內容數據），是通過MD5算法計算的內容的摘要信息。也就是說如果服務器內容不發生改變，則ETag每次都是一樣的，即服務器端的內容沒有發生改變。 **此處只列舉了部分緩存控制，詳細介紹超出了本書的范圍，強烈推薦：[http://www.mnot.net/cache_docs/](http://www.mnot.net/cache_docs/)（中文版[http://www.chedong.com/tech/cache_docs.html](http://www.chedong.com/tech/cache_docs.html)）?詳細了解HTTP緩存控制及為什么要緩存。** **緩存的目的是減少相應延遲?和?減少網絡帶寬消耗，比如css、js、圖片這類靜態資源應該進行緩存。** **實際項目一般使用反向代理服務器（如nginx、apache等）進行緩存。** [ 私塾在線學習網](http://sishuok.com/)原創內容（[http://sishuok.com](http://sishuok.com/)）原創內容，轉載請注明私塾在線【[http://sishuok.com/forum/blogPost/list/0/5234.html](http://sishuok.com/forum/blogPost/list/0/5234.html)】