Spring MVC

1、簡介

1.1 Web MVC

在Web開發中，通常是瀏覽器發送請求到服務器，由服務器接收請求並將響應傳遞給客戶端，並由客戶端渲染之後展示給用戶。因此，一般服務器是無法主動通知客戶端更新內容的，雖然有些推送技術可以實現主動通知客戶端。

在標準的MVC裡，服務器是可以主動將數據推送給客戶端的，但是實際的WebMVC是做不到的，如果用戶想要視圖更新，需要再發送一次請求。

Web端的開發經歷了從CGI->Servlet->JSP->Model1->Model2->Front Controller+PageController的過程：

• CGI：(Common Gateway Interface)公共網關接口，用於接收web用戶請求並處理，最後動態產生響應給用戶，但每次請求將產生一個進程，重量級。
• Servlet：接收web用戶請求並處理，最後動態產生響應給用戶。但每次請求只產生一個線程（而且有線程池），輕量級。本質就是在java代碼裡面 輸出 html流。
• JSP：運行在標準的HTML頁面中嵌入腳本語言，本質就是在html代碼中嵌入java代碼。JSP最終還是會被編譯為Servlet。
• Model1：JSP的增強版，可以認為是jsp+javabean，使用jsp:useBean標準動作簡化javabean的獲取/創建，及將請求參數封裝到javabean。
• Model2：Web MVC模型，只是控制器採用Servlet、模型採用JavaBean、視圖採用JSP。
• Front Controller+PageController：即前端控制器+應用控制器+頁面控制器（也有稱其為動作）+上下文，也是Web MVC，只是責任更加明確。

1.2 Spring MVC

Spring MVC與Spring搭配可以為我們提供強大的功能，更加簡潔的配置方式。以下是Spring Web MVC處理請求的流程：

從上面的圖中，我們總結Spring MVC的請求處理流程。當用戶發送請求之後：

1. 用戶請求達到前端控制器，前端控制器根據URL找到處理請求的控制器，並把請求委託給它；
2. 控制器收到請求之後會調用業務處理對象對其進行處理，並對得到的數據模型進行處理從而得到ModelAndView，並將其返回給前端控制器；
3. 前端控制器根據返回的視圖名選擇相應的視圖進行渲染，並把最終的響應返回給用戶。

結合Spring MVC框架中具體的類，我們又可以得到下面的這張更加詳盡的圖：

在SpringMVC中的核心的類是DispatcherServlet，根據上面的分析，它可以算的上是中間調度的橋樑。我們引入Spring MVC的依賴之後看下相關的代碼。 在DispatcherServlet中核心的方法是doDispatch()，下面是它的代碼：

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { HttpServletRequest processedRequest = request; HandlerExecutionChain mappedHandler = null; boolean multipartRequestParsed = false; WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); try { try { ModelAndView mv = null; Object dispatchException = null; try { // 1.首先查看是否是Multipart，即是否包含要上傳的文件 processedRequest = this.checkMultipart(request); multipartRequestParsed = processedRequest != request; // 2.根據請求和handlerMappings(列表)，找到對應的HandlerExecutionChain mappedHandler = this.getHandler(processedRequest); if (mappedHandler == null || mappedHandler.getHandler() == null) { this.noHandlerFound(processedRequest, response); return; } // 3.同樣的方式，從一個HandlerAdapter的列表中獲取到對應的HandlerAdapter HandlerAdapter ha = this.getHandlerAdapter(mappedHandler.getHandler()); String method = request.getMethod(); boolean isGet = "GET".equals(method); if (isGet || "HEAD".equals(method)) { long lastModified = ha.getLastModified(request, mappedHandler.getHandler()); if (this.logger.isDebugEnabled()) { this.logger.debug("Last-Modified value for [" + getRequestUri(request) + "] is: " + lastModified); } if ((new ServletWebRequest(request, response)).checkNotModified(lastModified) && isGet) { return; } } // 4.執行處理器相關的攔截器的預處理 if (!mappedHandler.applyPreHandle(processedRequest, response)) { return; } // 5.由適配器執行處理器（調用處理器相應功能處理方法），注意返回了ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler()); if (asyncManager.isConcurrentHandlingStarted()) { return; } this.applyDefaultViewName(processedRequest, mv); // 6.執行處理器相關的攔截器的後處理 mappedHandler.applyPostHandle(processedRequest, response, mv); } catch (Exception var20) { dispatchException = var20; } catch (Throwable var21) { dispatchException = new NestedServletException("Handler dispatch failed", var21); } // 7.處理分發結果，其中包含了一部分異常處理，也包括根據視圖名稱獲取視圖解析器並進行渲染等等 this.processDispatchResult(processedRequest, response, mappedHandler, mv, (Exception)dispatchException); } catch (Exception var22) { this.triggerAfterCompletion(processedRequest, response, mappedHandler, var22); } catch (Throwable var23) { this.triggerAfterCompletion(processedRequest, response, mappedHandler, new NestedServletException("Handler processing failed", var23)); } } finally { if (asyncManager.isConcurrentHandlingStarted()) { if (mappedHandler != null) { mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response); } } else if (multipartRequestParsed) { // 清理multipart請求佔用的資源 this.cleanupMultipart(processedRequest); } }}// 該方法用來處理從處理器拿到的結果，不論是異常還是得到的ModelAndView都會被處理private void processDispatchResult(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, ModelAndView mv, Exception exception) throws Exception { boolean errorView = false; // 處理異常信息 if (exception != null) { if (exception instanceof ModelAndViewDefiningException) { this.logger.debug("ModelAndViewDefiningException encountered", exception); mv = ((ModelAndViewDefiningException)exception).getModelAndView(); } else { Object handler = mappedHandler != null ? mappedHandler.getHandler() : null; mv = this.processHandlerException(request, response, handler, exception); errorView = mv != null; } } // 解析視圖並進行視圖的渲染  if (mv != null && !mv.wasCleared()) { // 實際的渲染方法，會根據ModelAndView的名稱找到對應的視圖解析器，並渲染得到一個視圖View this.render(mv, request, response); if (errorView) { WebUtils.clearErrorRequestAttributes(request); } } else if (this.logger.isDebugEnabled()) { this.logger.debug("Null ModelAndView returned to DispatcherServlet with name '" + this.getServletName() + "': assuming HandlerAdapter completed request handling"); } if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) { if (mappedHandler != null) { mappedHandler.triggerAfterCompletion(request, response, (Exception)null); } }}

所以，我們可以總結Spriung MVC的工作原理如下：

1. 用戶發送的請求首先會到達DispatcherServlet，並由它進行處理；
2. DispatcherServlet先通過HandlerMapping找到該請求對應的HandlerExecutionChain（包含一個Handler處理器、多個HandlerInterceptor攔截器），通過這種策略模式，很容易添加新的映射策略；
3. 然後DispatcherServlet繼續將請求發送給HandlerAdapter，HandlerAdapter會把處理器包裝為適配器，從而支持多種類型的處理器，即適配器設計模式，從而很容易支持很多類型的處理器；
4. HandlerAdapter將會根據適配的結果調用真正的處理器的功能處理方法，完成功能處理，並返回一個ModelAndView對象（包含模型數據、邏輯視圖名）；
5. 再由DispatcherServlet根據ModelAndView找到對應的ViewResolver，並由它把邏輯視圖名解析為具體的View，通過這種策略模式，很容易更換其他視圖技術；
6. 接下來會對View進行渲染，View會根據傳進來的Model模型數據進行渲染，Model實際是一個Map數據結構，因此很容易支持其他視圖技術；
7. 返回控制權給DispatcherServlet，由DispatcherServlet返回響應給用戶，到此一個流程結束。

2、使用Spring MVC

2.1 Spring MVC基於XML的配置方式

首先，要使用Spring MVC需要加入相關的依賴：

 org.springframework spring-webmvc  
${spring.version}

我們上面分析過的DispatcherServlet是註冊到web.xml裡面的，我們需要加入如下的配置：

Archetype Created Web Applicationspring_is_comingorg.springframework.web.servlet.DispatcherServlet1spring_is_coming*.mvc

這裡我們註冊了一個servlet，即上面提到的DispatcherServlet，併為其指定一個名稱為spring_is_coming。對應的，我們還要為其指定一個servlet-mapping。 如上所示，我們在url-pattern中指定了該servlet要處理的url的模式，即所有以*.mvc結尾的url。load-on-startup表示啟動容器時初始化該Servlet。

默認情況下，DispatcherServlet會加載WEB-INF/[DispatcherServlet的Servlet名字]-servlet.xml下面的配置文件。根據上面的配置我們需要在當前項目的WEB-INF目錄下面加入spring_is_coming-servlet.xml文件。並在該文件中加入如下的代碼：

接下來我們定義了一個控制器，該控制器的名字對應於指定的url。因為之前我們使用了Bean的映射規則是BeanNameUrlHandlerMapping，也就是說Bean的名稱和url對應。

然後就是上面定義的那個控制器的代碼：

public class HelloController implements Controller { @Override public ModelAndView handleRequest(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse) throws Exception { ModelAndView mv = new ModelAndView(); // 添加模型數據 可以是任意的POJO對象 mv.addObject("message", "Hello Spring MVC!"); // 設置邏輯視圖名，視圖解析器會根據該名字解析到具體的視圖頁面 mv.setViewName("hello"); return mv; }}

這裡我們用了ModelAndView.setViewName()為該ModelAndView指定了對應的jsp文件的名稱，會按照我們上面配置的視圖解析的規則到指定目錄下記載指定名稱的文件。

啟動服務器，在瀏覽器中輸入地址：http://localhost:8080/hello.mvc，進行測試即可。

2.2 使用過濾器

我們還可以在分發器處理請求之前對其進行處理，我們通過過濾器來實現。我們可以用過濾器來做一些基礎的工作，比如字符串編碼之類的問題。下面我們通過一個自定義的簡單的例子來演示一下過濾器的使用：

首先，我們自定義一個簡單的過濾器，並在其中輸出一些信息到控制檯上：

public class TheFilter implements Filter { @Override public void init(FilterConfig filterConfig) throws ServletException { System.out.println("init, filterConfig" + filterConfig); } @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException { System.out.println("==================================== doFilter, servletRequest: " + servletRequest + "\nservletResponse: " + servletResponse + "\nfilterChain: " + filterChain); // 必須調用這個方法，否則請求就要在這裡被攔截了 filterChain.doFilter(servletRequest, servletResponse); } @Override public void destroy() { System.out.println("destroy"); }}

 the_filter me.shouheng.spring.mvc.TheFilter the_filter *.mvc

這樣我們就可以對所有以*.mvc結尾的請求進行處理了。

2.3 DispatcherServlet詳解

實際上DispatcherServlet是Servlet的一種，也就是當我們使用Spring MVC的時候需要配置該類，因為它是Spring MVC的核心配置類。而當我們不打算使用Spring MVC而想要為其他客戶端提供接口的時候就需要配置其他類型的Servlet，不過它們的配置和在Servlet種被使用的原理都是一樣的。。

上面我們已經提到過了DispatcherServlet的兩個參數的意義，並且使用了配置文件spring_is_coming-servlet.xml。而實際上為DispatcherServlet指定配置文件的方式可以有多種：

第一種，默認會使用[DispatcherServlet的Servlet名字]-servlet.xml這種命名規則到WEB-INF目錄下面加載該文件，這也是我們上面使用的方式。

第二種方式是在配置servlet的時候，在標籤中使用contextClass，並且指定一個配置類，該配置類需要實現WebApplicationContext接口的類。如果這個參數沒有指定， 默認使用XmlWebApplicationContext。

第三種方式是與第二種類似，都是在配置servlet的時候指定，不過這裡使用的是contextConfigLocation，並用字符串來指定上下文的位置。這個字符串可以被分成多個字符串（使用逗號作為分隔符） 來支持多個上下文（在多上下文的情況下，如果同一個bean被定義兩次，後面一個優先）。如下所示：

  chapter2 org.springframework.web.servlet.DispatcherServlet 1  contextConfigLocation classpath:spring-servlet-config.xml  

通常在我們配置上下文的時候會指定多個上下文，各個上下文也有自己的職責範圍。除了之前我們配置的Servlet的上下文，在使用Spring的時候，我們還需要配置整個應用的上下文：

 contextConfigLocation  classpath:spring-common-config.xml, classpath:spring-budget-config.xml  org.springframework.web.context.ContextLoaderListener

這裡配置的就是整個應用的上下文，配置的ContextLoaderListener會在容器啟動的時候自動初始化應用程序上下文。而該應用程序上下文的配置文件就由上面的context-param來指定。應用程序上下文通常用來加載整個程序的基礎類，比如DAO層和Service層等。這樣它們就可以與任何其他的Web層配合使用。而Servlet配置的上下文通常用來加載Web層需要的類，比如Controller、HandlerMapping、HandlerAdapter等等。

2.4 攔截器

在DispatcherServlet種攔截器處理的邏輯是非常簡單易懂的。DispatcherServlet會在的核心方法doDispatch()的不同的處理階段調用HandlerExecutionChain的三個方法（在新版本的Spring中相關的邏輯被抽取出來封裝成了獨立的方法）。

1. HandlerExecutionChain.applyPreHandle()會在Contoller的方法被執行之前調用；
2. HandlerExecutionChain.applyPostHandle()會在Contoller的方法被執行之後，並且視圖被渲染之前調用，如果中間出現異常則不會被調用；`
3. HandlerExecutionChain.triggerAfterCompletion()會在Contoller的視圖被渲染之後調用，無論是否異常，總是被調用；

那麼，在這三個方法中又做了什麼呢？下面就是相關的邏輯，實際上三個方法是類似的，即從一個數組中取出定義的攔截器進行遍歷調用：

boolean applyPreHandle(HttpServletRequest request, HttpServletResponse response) throws Exception { HandlerInterceptor[] interceptors = this.getInterceptors(); if (!ObjectUtils.isEmpty(interceptors)) { for(int i = 0; i < interceptors.length; this.interceptorIndex = i++) { HandlerInterceptor interceptor = interceptors[i]; if (!interceptor.preHandle(request, response, this.handler)) { this.triggerAfterCompletion(request, response, (Exception)null); return false; } } } return true;}

所以，這部分的邏輯也不復雜。那麼，那麼我們看下如何在Spring MVC中使用攔截器：

我們還是在之前的spring_is_coming-servlet.xml中加入上面的幾行代碼，這裡我們用到了一個自定義的攔截器，下面我們給出它的定義：

public class TestInterceptor extends HandlerInterceptorAdapter { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { System.out.println("=========preHandle"); return super.preHandle(request, response, handler); } @Override public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception { System.out.println("=========postHandle"); super.postHandle(request, response, handler, modelAndView); } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { System.out.println("=========afterCompletion"); super.afterCompletion(request, response, handler, ex); } @Override public void afterConcurrentHandlingStarted(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { System.out.println("=========afterConcurrentHandlingStarted"); super.afterConcurrentHandlingStarted(request, response, handler); }}

然後，我們使用標籤定義了對應的攔截器及其要匹配的路徑。這樣當訪問指定的url時，在觸發響應的Controller的時候就會調用到我們定義的攔截器。

這裡我們還要說明一下HandlerInterceptorAdapter中的幾個方法。 實際上所有的攔截器最終都是實現了接口HandlerInterceptor，而上面的類中的前三個方法實際上就是來自於該接口。 在preHandle()的返回值默認是true，表示當前攔截器處理完畢之後會繼續讓下一個攔截器來處理。 實際上參考上面的HandlerExecutionChain.applyPreHandle()方法也能看出這一點。

2.5 基於註解的配置方式

在基於註解的配置方式中，我們需要對上面的配置做一些修改。首先，我們使用基於註解的適配器和映射機制。在spring_is_coming-servlet.xml中，我們將之前的代碼替換為：

注意上面的這兩行代碼是Spring 3.1之後的配置方式，而3.1之前的代碼在最新的Spring版本中已經移除，不再贅訴。

然後，我們定義如下的Controller：

@Controllerpublic class HelloController3 { @RequestMapping(value = "/hello3") public ModelAndView handle() { ModelAndView mv = new ModelAndView(); // 添加模型數據 可以是任意的POJO對象 mv.addObject("message", "Hello Spring MVC!"); // 設置邏輯視圖名，視圖解析器會根據該名字解析到具體的視圖頁面 mv.setViewName("hello3"); return mv; }}

這裡的配置方式和之前基於Bean名稱映射的機制類似，只是這裡使用都是基於註解的配置方式。在作為Controller使用的類上面，我們要使用@Controller註解，具體的業務層方法上面使用@RequestMapping註解並指定映射的路徑。然後，我們將該Bean註冊到上下文當中：

這樣基本的配置方式就已經完成了。然後，運行Web容器並輸入url:http://localhost:8080/hello3即可。還要注意下，還要修改web.xml中的Servlet的匹配路徑，如果是*.mvc的話要改成/。

其實這裡的配置方式和之前的配置方式唯一的區別也就在於，將映射的規則從之前的Bean名到url轉換成了註解到url。

除了上面的那種方式配置url路徑，我們還可以添加各種子路徑。比如：

@Controller@RequestMapping("/user")public class HelloController3 { @RequestMapping(value = "/hello3") public ModelAndView handle() { ModelAndView mv = new ModelAndView(); // 添加模型數據 可以是任意的POJO對象 mv.addObject("message", "Hello Spring MVC!"); // 設置邏輯視圖名，視圖解析器會根據該名字解析到具體的視圖頁面 mv.setViewName("hello3"); return mv; }}

按照上面的方式，將會匹配到：/user/hello3。

2.6 RequestMapping註解

從上面看出使用註解的配置方式中，核心的配置應該屬於@RequestMapping註解。下面是該註解的定義：

public @interface RequestMapping { String name() default ""; @AliasFor("path") String[] value() default {}; @AliasFor("value") String[] path() default {}; RequestMethod[] method() default {}; String[] params() default {}; String[] headers() default {}; String[] consumes() default {}; String[] produces() default {};}

其中:

1. name用來為當前的控制器指定一個名稱；
2. value和path是等價的，都是用來指定url的匹配規則的；
3. method用來指定匹配的方法，比如POST, GET等等；
4. consumes用來指定請求的提交內容類型（Content-Type），例如application/json, text/html；
5. params：指定request中必須包含某些參數值是，才讓該方法處理；
6. headers：指定request中必須包含某些指定的header值，才能讓該方法處理請求；
7. produces：指定request中必須包含某些指定的header值，才能讓該方法處理請求；

下面我們對其中的幾個方法進行簡單說明。

2.6.1 value和path

這兩個參數的效果是等價的，因為它們相互之間只是一個別名的關係。這兩個參數用來指定該控制器要映射的url，這裡我們列舉一下常見的url映射配置方式：

1. @RequestMapping(value={"/test1", "/user/create"})：多個URL路徑映射到同一個處理器；
2. @RequestMapping(value="/users/{userId}")：使用url佔位符，如"/users/123456"或"/users/abcd"，通過@PathVariable可以提取URI模板模式中的變量；
3. @RequestMapping(value="/users/**")：可以匹配“/users/abc/abc”，但“/users/123”將會被2中的模式優先映射到；
4. @RequestMapping(value="/product?")：可匹配“/product1”或“/producta”，但不匹配“/product”或“/productaa”；
5. @RequestMapping(value="/product*")：可匹配“/productabc”或“/product”，但不匹配“/productabc/abc”；
6. @RequestMapping(value="/product/*")：可匹配“/product/abc”，但不匹配“/productabc”
7. @RequestMapping(value="/products/**/{productId}")：可匹配“/products/abc/abc/123”或“/products/123”；
8. 基於正則表達式的方式。

配置方式2方式的特別說明，指定路徑中的參數並在方法中獲取參數的具體示例：

@RequestMapping("/testPathVariable/{id}")public String testPathVariable(@PathVariable("id") Integer id2) { System.out.println("testPathVariable: " + id2); return SUCCESS;}

2.6.2 params

該參數用來限制只有當請求中包含指定參數名的數據時才會被處理，比如:

@Controller@RequestMapping("/parameter1") //①處理器的通用映射前綴public class RequestParameterController1 { @RequestMapping(params="create", method=RequestMethod.GET)  public String showForm() { .... } @RequestMapping(params="create", method=RequestMethod.POST)  public String submit() { ....  }}

其中的第一個方法表示請求中有“create”的參數名且請求方法為“GET”即可匹配，如可匹配的請求URL“http://×××/parameter1?create”； 第二個方法表示請求中有“create”的參數名且請求方法為“POST”即可匹配。

當然你還可以進一步限制當請求中包含指定的參數並且為指定的值時才能被處理，比如@RequestMapping(params="submitFlag=create", method=RequestMethod.GET)：表示請求中有“submitFlag=create”且請求方法為“GET”才可匹配。

還要注意，從@RequestMapping中的params定義中可以看出，它是一個數組，當指定多個值的時候，這些值之間屬於'且'的關係，即兩個參數同時包含才行。

2.6.3 consumes

consumes用來指定該控制器要處理的請求的數據類型，所謂媒體類型就是指text/plain application/json等等。 它們會被放在請求的請求頭中，比如Content-Type: application/x-www-form-urlencoded表示請求的數據為key/value數據， 只有當請求數據與控制器在@RequestMapping中指定的數據相同的時候，指定的請求才會被該控制器處理。

@RequestMapping(value = "/testMethod", method = RequestMethod.POST,consumes="application/json")public String testMethod() { System.out.println("testMethod"); return SUCCESS;}

比如以上控制器只接受json類型的數據。當請求的數據非json的時候是不會被其處理的。

2.6.4 produces

produces用來指定當前的請求希望得到什麼類型的數據，這個參數在請求的時候會被放到請求頭的Accept中。 只有當請求的Accept類型與控制器中使用produces指定的類型相同的時候才會被該控制器接受並處理。

2.6.5 headers

如果說前面的consumes和produces用來指定請求的和希望得到的數據類型是一種特例的話， 那麼這裡的headers則是可以用來更加靈活地指定headers中需要包含那些信息才能被當前的控制器處理。 比如：

@RequestMapping(value = "testParamsAndHeaders", params = { "username","age!=10" }, headers = { "Accept-Language=US,zh;q=0.8" })public String testParamsAndHeaders() { System.out.println("testParamsAndHeaders"); return SUCCESS;}

用來設定請求頭中第一語言必須為US。

3、其他

3.1 攔截器和過濾器的區別

1. 攔截器是基於java的反射機制的，過濾器是基於函數回調；
2. 攔截器不依賴於servlet容器，過濾器依賴於servlet容器，因為過濾器是Servlet規範規定的，只用於Web程序中，而攔截器可以用在Appliaction和Swing等中；
3. 在Action的生命週期中，攔截器可以多次被調用，而過濾器只能在容器初始化時被調用一次；
4. 攔截器可以獲取IOC容器中的各個bean，而過濾器就不行，這點很重要，在攔截器裡注入一個service，可以調用業務邏輯;
5. 過濾器是在請求進入容器後，但請求進入servlet之前進行預處理的。請求結束返回也是，是在servlet處理完後，返回給前端之前。

實際上從上面的配置中也可以看出來，過濾器在請求達到Servlet之前被調用的，它屬於Servlet而不屬於Spring。

閱讀更多 JAVA小酷 的文章

關鍵字: JSP 總結 編程語言