Spring：一篇文章總結 Spring MVC

時間  2019-11-29
標籤 spring 一篇 文章 總結 mvc 欄目 Spring 简体版
原文   原文鏈接

一、簡介

1.1 Web MVC

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

在標準的MVC裏，服務器是能夠主動將數據推送給客戶端的，可是實際的WebMVC是作不到的，若是用戶想要視圖更新，須要再發送一次請求。前端

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

  • 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處理請求的流程：web

Spring Web MVC處理請求的流程

從上面的圖中，咱們總結Spring MVC的請求處理流程。當用戶發送請求以後：正則表達式

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

結合Spring MVC框架中具體的類，咱們又能夠獲得下面的這張更加詳盡的圖：spring

Spring Web MVC架構

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

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返回響應給用戶，到此一個流程結束。

二、使用Spring MVC

2.1 Spring MVC基於XML的配置方式

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

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${spring.version}</version>
</dependency>
複製代碼

咱們上面分析過的DispatcherServlet是註冊到web.xml裏面的，咱們須要加入以下的配置：瀏覽器

<!DOCTYPE web-app PUBLIC
		"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
		"http://java.sun.com/dtd/web-app_2_3.dtd" >
<web-app>
	<display-name>Archetype Created Web Application</display-name>

	<servlet>
		<servlet-name>spring_is_coming</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>spring_is_coming</servlet-name>
		<url-pattern>*.mvc</url-pattern>
	</servlet-mapping>
</web-app>
複製代碼

這裏咱們註冊了一個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文件。並在該文件中加入以下的代碼：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"
       xmlns:p="http://www.springframework.org/schema/p">

    <!-- HandlerMapping -->
    <bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/>

    <!-- HandlerAdapter -->
    <bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"/>

    <!-- ViewResolver -->
    <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
        <property name="prefix" value="/WEB-INF/jsp/"/>
        <property name="suffix" value=".jsp"/>
    </bean>

    <bean name="/hello.mvc" class="me.shouheng.spring.mvc.HelloController"/>

</beans>
複製代碼

這裏咱們聲明瞭幾個Bean，即HandlerMapping和HandlerAdapter的默認實現。而後，咱們還定義了一個視圖解析器InternalResourceViewResolver。 它是一個默認的視圖解析器，在它的屬性配置中，咱們指定了加載的文件的前綴和後綴路徑。實際上，當咱們指定某個視圖名字爲hello，那麼該視圖解析器就會加載文件 /WEB-INF/jsp/hello.jsp。

接下來咱們定義了一個控制器，該控制器的名字對應於指定的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");
    }
}
複製代碼

這裏咱們要實現Fileter接口的三個與聲明週期相關的方法。而後，將其配置到web.xml中就能夠了：

<filter>
    <filter-name>the_filter</filter-name>
    <filter-class>me.shouheng.spring.mvc.TheFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>the_filter</filter-name>
    <url-pattern>*.mvc</url-pattern>
</filter-mapping>
複製代碼

這樣咱們就能夠對全部以*.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的時候，在<servlet>標籤中使用contextClass，而且指定一個配置類，該配置類須要實現WebApplicationContext接口的類。若是這個參數沒有指定， 默認使用XmlWebApplicationContext。

第三種方式是與第二種相似，都是在配置servlet的時候指定，不過這裏使用的是contextConfigLocation，並用字符串來指定上下文的位置。這個字符串能夠被分紅多個字符串（使用逗號做爲分隔符） 來支持多個上下文（在多上下文的狀況下，若是同一個bean被定義兩次，後面一個優先）。以下所示：

<servlet>
        <servlet-name>chapter2</servlet-name>
        <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
        <init-param>
            <param-name>contextConfigLocation</param-name>
            <param-value>classpath:spring-servlet-config.xml</param-value>
        </init-param>
    </servlet>
複製代碼

一般在咱們配置上下文的時候會指定多個上下文，各個上下文也有本身的職責範圍。除了以前咱們配置的Servlet的上下文，在使用Spring的時候，咱們還須要配置整個應用的上下文：

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
         classpath:spring-common-config.xml,
         classpath:spring-budget-config.xml
    </param-value>
</context-param>
<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
複製代碼

這裏配置的就是整個應用的上下文，配置的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中使用攔截器：

<bean name="interceptor" class="me.shouheng.spring.mvc.TestInterceptor"/>

<mvc:interceptors>
    <mvc:interceptor>
        <mvc:mapping path="/hello2.mvc"/>
        <ref bean="interceptor"/>
    </mvc:interceptor>
</mvc:interceptors>
複製代碼

咱們仍是在以前的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);
    }
}
複製代碼

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

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

2.5 基於註解的配置方式

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

<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping"/>

<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"/>
複製代碼

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

而後，咱們定義以下的Controller：

@Controller
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;
    }
}
複製代碼

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

<bean class="me.shouheng.spring.mvc.HelloController3"/>
複製代碼

這樣基本的配置方式就已經完成了。而後，運行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.1 攔截器和過濾器的區別

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

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

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程