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的請求處理流程。當用戶發送請求之后:
- 用戶請求達到前端控制器,前端控制器根據URL找到處理請求的控制器,并把請求委托給它;
- 控制器收到請求之后會調用業務處理對象對其進行處理,并對得到的數據模型進行處理從而得到ModelAndView,并將其返回給前端控制器;
- 前端控制器根據返回的視圖名選擇相應的視圖進行渲染,并把最終的響應返回給用戶。
結合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的工作原理如下:
- 用戶發送的請求首先會到達
DispatcherServlet
,并由它進行處理; -
DispatcherServlet
先通過HandlerMapping
找到該請求對應的HandlerExecutionChain
(包含一個Handler
處理器、多個HandlerInterceptor
攔截器),通過這種策略模式,很容易添加新的映射策略; - 然后
DispatcherServlet
繼續將請求發送給HandlerAdapter
,HandlerAdapter
會把處理器包裝為適配器,從而支持多種類型的處理器,即適配器設計模式,從而很容易支持很多類型的處理器; -
HandlerAdapter
將會根據適配的結果調用真正的處理器的功能處理方法,完成功能處理,并返回一個ModelAndView
對象(包含模型數據、邏輯視圖名); - 再由
DispatcherServlet
根據ModelAndView
找到對應的ViewResolver
,并由它把邏輯視圖名解析為具體的View
,通過這種策略模式,很容易更換其他視圖技術; - 接下來會對
View
進行渲染,View
會根據傳進來的Model
模型數據進行渲染,Model實際是一個Map數據結構,因此很容易支持其他視圖技術; - 返回控制權給
DispatcherServlet
,由DispatcherServlet
返回響應給用戶,到此一個流程結束。
2、使用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中相關的邏輯被抽取出來封裝成了獨立的方法)。
-
HandlerExecutionChain.applyPreHandle()
會在Contoller
的方法被執行之前調用; -
HandlerExecutionChain.applyPostHandle()
會在Contoller
的方法被執行之后,并且視圖被渲染之前調用,如果中間出現異常則不會被調用;` -
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 {};
}
其中:
-
name
用來為當前的控制器指定一個名稱; -
value
和path
是等價的,都是用來指定url的匹配規則的; -
method
用來指定匹配的方法,比如POST, GET等等; -
consumes
用來指定請求的提交內容類型(Content-Type),例如application/json, text/html; -
params
:指定request中必須包含某些參數值是,才讓該方法處理; -
headers
:指定request中必須包含某些指定的header值,才能讓該方法處理請求; -
produces
:指定request中必須包含某些指定的header值,才能讓該方法處理請求;
下面我們對其中的幾個方法進行簡單說明。
2.6.1 value和path
這兩個參數的效果是等價的,因為它們相互之間只是一個別名的關系。這兩個參數用來指定該控制器要映射的url,這里我們列舉一下常見的url映射配置方式:
-
@RequestMapping(value={"/test1", "/user/create"})
:多個URL路徑映射到同一個處理器; -
@RequestMapping(value="/users/{userId}")
:使用url占位符,如"/users/123456"或"/users/abcd",通過@PathVariable
可以提取URI模板模式中的變量; -
@RequestMapping(value="/users/**")
:可以匹配“/users/abc/abc”,但“/users/123”將會被2中的模式優先映射到; -
@RequestMapping(value="/product?")
:可匹配“/product1”或“/producta”,但不匹配“/product”或“/productaa”; -
@RequestMapping(value="/product*")
:可匹配“/productabc”或“/product”,但不匹配“/productabc/abc”; -
@RequestMapping(value="/product/*")
:可匹配“/product/abc”,但不匹配“/productabc” -
@RequestMapping(value="/products/**/{productId}")
:可匹配“/products/abc/abc/123”或“/products/123”; - 基于正則表達式的方式。
配置方式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 攔截器和過濾器的區別
- 攔截器是基于java的反射機制的,過濾器是基于函數回調;
- 攔截器不依賴于servlet容器,過濾器依賴于servlet容器,因為過濾器是Servlet規范規定的,只用于Web程序中,而攔截器可以用在Appliaction和Swing等中;
- 在Action的生命周期中,攔截器可以多次被調用,而過濾器只能在容器初始化時被調用一次;
- 攔截器可以獲取IOC容器中的各個bean,而過濾器就不行,這點很重要,在攔截器里注入一個service,可以調用業務邏輯;
- 過濾器是在請求進入容器后,但請求進入servlet之前進行預處理的。請求結束返回也是,是在servlet處理完后,返回給前端之前。
實際上從上面的配置中也可以看出來,過濾器在請求達到Servlet之前被調用的,它屬于Servlet而不屬于Spring。