摘要
任何一個完備的MVC框架都需要解決Web開發過程中的一些共性的問題,比如請求的收集與分發、數據前後臺流轉與轉換,當前最流行的SpringMVC和Struts2也不例外。本文首先概述MVC模式的分層思想與MVC框架普遍關注的問題,並以此爲契機結合SpringMVC的入門級案例簡要地從原理、架構角度介紹了它對這些問題的處理,包括請求處理流程、消息轉換機制和數據綁定機制等核心問題。最後,本文對目前最爲流行的兩個MVC框架SpringMVC 和 Struts2作了進一步對比,以便加強對MVC框架的理解與認知。
一. MVC 模式與框架
1、MVC 模式
Java Web 應用的結構經歷了 Model1 和 Model2 兩個時代。在 Model1 模式下,整個 Web 應用幾乎全部用JSP頁面組成,只用少量的JavaBean來處理數據庫連接、訪問等操作。從工程化角度來看,JSP 不但充當了表現層角色,還充當了控制器角色,將控制邏輯和表現邏輯混雜在一起,導致代碼重用率極低,使得應用極難擴展和維護。
Model2 已經是基於MVC架構的設計模式。在 Model2 中,Servlet 作爲控制器,負責接收客戶端發送的請求,調用後端的JavaBean(業務邏輯組件)來處理業務邏輯並根據處理結果轉發到相應的JSP頁面處理顯示邏輯。在 Model2 模式下,模型(Model)由 JavaBean 充當,視圖(View)由JSP頁面充當,而控制器則由 Servlet 充當。Model2 的流程示意圖如下:
更具體地,在 Model2(標準MVC)中,角色分工如下:
組件 | 功能 |
---|---|
Model | 由 JavaBean 充當,所有的業務邏輯、數據庫訪問都在Model中實現; |
View | 由 JSP 充當,負責收集用戶請求參數並將應用處理結果、狀態數據呈現給用戶; |
Controller | 由 Servlet 充當,作用類似於調度員,即所有用戶請求都發送給 Servlet,Servlet 調用 Model 來處理用戶請求,並根據處理結果調用 JSP 來呈現結果;或者Servlet直接調用JSP將應用處理結果展現給用戶。 |
2、MVC 框架
上述提到的MVC模式只是一種分層架構思想,並不包含任何具體的實現。在Model2中,我們分別爲使用JavaBean、JSP和 Servlet分別充當模型(Model)、視圖(View)和控制器,這可以看作是MVC模式最爲基本的一種實現。但實際上,開發者使用Model2來開發Java WEB應用時,除了要專注於業務邏輯的開發以外,還需要額外考慮各種各樣的問題,比如前後臺數據之間的流轉和轉換問題、數據驗證問題、消息轉換問題等等,而且並沒有實現各層之間的完全解耦。Model2存在的這些問題實際上都是一些共性的問題,換言之,Model2的抽象和封裝程度還遠遠不夠,開發者在使用Model2進行開發時不可避免地會重複造輪子,這就大大降低了程序的可維護性和複用性。
爲了解決這一問題,解放廣大程序員的雙手,一些MVC框架就應運而生了。Struts是全世界最早的MVC框架,特別地,其與WebWork分娩出的Struts2擁有衆多優秀的設計,而且吸收了傳統的Struts和WebWork兩者的精華,曾一度是MVC框架中的王者。但是,與SpringMVC相比,Struts2又顯得如此笨重、難用。與此同時,隨着Spring的廣泛應用和開發者對輕量級框架的不懈追求,SpringMVC逐漸成爲MVC框架中新的王者。
讓開發者只關注於業務邏輯的處理是MVC框架的終極目標。無論是昔日的Struts2還是今天的SpringMVC,它們的差別更多體現在設計上的優劣與細膩,但是作爲一個MVC框架,它們都會封裝並提供一些基本的組件和功能以便解放程序員的雙手,比如:
- 分發請求的前端控制器(Struts2中的StrutsPrepareAndExecuteFilter和SpringMVC中的DispatcherServlet);
- 處理請求的業務控制器(Struts2中的Action和SpringMVC中的Controller);
- 請求URI與請求處理方法的匹配(Struts2中的ActionMapper和SpringMVC中的HandlerMapping);
- 請求處理方法的調用(Struts2中的ActionProxy和SpringMVC中的HandlerAdapter);
- 類型轉換問題 —— 前後臺數據的流轉;
- 數據校驗;
- 異常配置;
- 國際化和標籤庫;
- 文件上傳/下載;
事實上,任何一個完備的MVC框架都會對以上功能進行抽象和封裝。與Model2相比,MVC框架提取並完成了大量實際開發中需要重複解決的通用步驟,留給開發者的僅僅是與特定應用相關的部分,從而大大簡化了程序的開發、提升程序的可維護性和增強代碼複用性。
二. Spring MVC 核心組件與執行流程
Spring MVC是Spring框架提供的構建Web應用程序的全功能MVC模塊,也是一種基於Java的實現了Web MVC設計模式的請求驅動類型的輕量級Web框架,很好地實現了MVC架構模式的思想並將web層進行職責解耦。一般地,在MVC框架中,控制器(Controller)用於執行業務邏輯併產生模型數據(Model),而視圖(View)則用於渲染模型數據,當然SpringMVC也不例外,如下圖所示:
1、SpringMVC 執行流程
上圖簡要地描述了SpringMVC中請求處理的流程,但實際上,它並沒有刻畫出SpringMVC框架處理一個HTTP請求的全貌。下圖詳細描述了SpringMVC的請求處理過程,並給出了SpringMVC各核心組件之間的交互過程。
- 用戶向服務器發送請求,請求被Spring MVC的前端控制器DispatcherServlet截獲;
- DispatcherServlet對請求URL(統一資源定位符)進行解析,得到URI(請求資源標識符)。然後根據該URI,調用HandlerMapping獲得該Handler配置的所有相關對象,包括Handler對象以及Handler對象對應的攔截器,這些對象會被封裝到一個 HandlerExecutionChain對象 當中返回;
- DispatcherServlet根據獲得的Handler,選擇一個合適的HandlerAdapter。一個HandlerAdapter會被用於處理多種(一類)Handler,並調用Handler實際處理請求的方法;
- 在調用Handler實際處理請求的方法之前,HandlerAdapter 首先會結合用戶配置對請求消息進行轉換(例如,將JSON/XML請求消息轉換成一個Java對象),然後通過DataBinder將請求中的模型數據綁定到Handler(Controller)對應的處理方法的參數中。在消息轉換和數據綁定過程中,Spring MVC會做一些額外的處理,比如數據類型轉換、數據格式化工作和數據合法性校驗等;
- Handler調用業務邏輯組件完成對請求的處理後,向DispatcherServlet返回一個ModelAndView對象,ModelAndView對象中應該包含視圖名或者視圖名和模型;
- DispatcherServlet根據返回的ModelAndView對象,選擇一個合適的ViewResolver(視圖解析器)返回給DispatcherServlet;
- DispatcherServlet調用視圖解析器ViewResolver結合Model來渲染視圖View;
- DispatcherServlet將視圖渲染結果返回給客戶端。
在以上八個步驟中,DispatcherServlet、HandlerMapping、HandlerAdapter和ViewResolver等核心組件相互配合來完成Spring MVC 請求-響應的整個工作流程。這些核心組件所完成的工作對開發者是透明的,也就是說,開發者並不需要關心這些組件是如何工作的,開發者只需要專注在Handler(Controller)當中完成對請求的業務邏輯處理即可,這也正是MVC框架的價值體現。
2、SpringMVC的消息轉換器機制:HttpMessageConveter
事實上,我們在向服務器進行請求時,可以採用各種各樣的數據交換格式,比如輕量級的JSON和重量級的XML,當然也可以是其他自定義的數據交換格式。但無論在請求發送端採用何種數據交換格式,我們從請求流中讀取到的只能是原始的字符串報文,同樣地我們往響應流中也只能寫原始的字符串。然而,在Java世界中,我們在調用模型組件處理業務邏輯時常常是以一個個有業務意義的對象爲處理維度的,那麼在請求消息到達SpringMVC和響應消息從SpringMVC出去的過程中就存在一個消息轉換的問題,即請求消息(字符串)到Java對象的轉換問題。
張小龍在談微信的本質時候說:“微信只是個平臺,消息在其中流轉”。在我們分析SpringMVC的消息轉換器機制時,也可以領悟到類似的道理。在SpringMVC的設計者眼中,一次請求報文和一次響應報文分別被抽象爲一個請求消息HttpInputMessage和一個響應消息HttpOutputMessage。在處理請求時,由合適的消息轉換器將請求消息轉換爲請求處理方法中的形參對象並通過DataBinder組件綁定到請求處理方法的形參上,在這裏,原始請求消息就可能有多種不同的形式,比如JSON和XML。同樣地,當Controller響應請求時,請求處理方法的返回值也可以不是html頁面,而是其他某種格式的數據,比如JSON和XML。
我們知道Struts2本身對諸如JSON和XML等數據交換格式的支持不是特別好,常常需要藉助於一些插件(比如,Struts2爲了彌補不能原生支持JSON的不足,提供了struts2-json-plugin插件)來完成;而在SpringMVC中,採用的是HttpMessageConverter機制。具體而言,HttpMessageConveter負責將請求信息轉換爲一個對象,並通過DataBinder組件將該對象綁定請求方法的參數中或輸出爲響應信息。特別地,SpringMVC針對常用的不同消息形式提供了不同的HttpMessageConverter實現類來處理他們,而且我們也很容易擴展自定義的消息轉換器。但是,只要這些消息所蘊含的“有效信息”是一致的,那麼各種不同的消息轉換器都會生成同樣的轉換結果。至於各種消息間解析細節的不同,就被屏蔽在不同的HttpMessageConverter實現類中了。
正如下文提到的那樣,在SpringMVC中可以使用@RequestBody和@ResponseBody兩個註解分別完成請求消息到對象和對象到響應消息的轉換,而底層這種靈活的消息轉換機制就是由HttpMessageConverter支持的。
3、SpringMVC的數據綁定組件:DataBinder
事實上,上一節提到的SpringMVC的消息轉換器機制HttpMessageConveter就是在SpringMVC的數據綁定組件DataBinder的基礎上實現的。在HandlerAdapter調用Handler中具體的方法處理請求前,HandlerAdapter會根據請求方法簽名的不同,將請求消息中的信息以一定的方式轉換並綁定到請求方法的參數中以便請求的處理。也就是說,在請求消息到達真正調用處理方法的這一段時間內,SpringMVC還會完成很多其它的工作,包括請求信息的轉換、數據轉換、數據格式化以及數據校驗等等。事實上,SpringMVC會通過反射機制對目標處理方法的簽名進行分析,並將請求消息綁定到處理方法的參數中。數據綁定的核心部件是DataBinder,其機制如下:
Spring MVC框架將ServletRequest對象及其處理方法的參數對象實例傳遞給DataBinder,DataBinder調用裝配在Spring Web 上下文中的ConversionService組件進行數據類型轉換、數據格式化工作,並將ServletRequest中的消息填充到參數對象中去。然後,再調用Validator組件對已經綁定了請求消息數據的參數對象進行數據合法性校驗,並最終生成數據綁定結果BindingResult對象。其中,BindingResult對象不但包含已完成數據綁定的參數對象,還包含相應的校驗錯誤對象,Spring MVC 會抽取BindingResult對象中的參數對象及校驗錯誤對象,並將它們賦給處理方法的相應參數。
4、小結
SpringMVC的請求處理流程可概括如下:當SpringMVC收到請求時,前端控制器DispatcherServlet會根據請求URI調用HandlerMapping將請求分發給具有一系列攔截器和業務控制器Controller的HandlerExecutionChain對象,然後該請求將依次通過該執行鏈的各個攔截器並最終到達業務控制器Controller。在業務控制器Controller處理該請求前,HandlerAdapter會對請求消息作進一步轉換和解析並綁定到業務控制器Controller的具體請求處理方法上,然後該方法根據結合請求參數調用一系列業務邏輯組件去處理請求,並將包含模型數據和具體視圖的處理結果交給視圖解析器ViewResolver進行渲染,最終DispatcherServlet將視圖渲染結果返回給客戶端。
從這個過程中我們可以直觀看到SpringMVC解決了一系列MVC框架最主要關注的問題,比如請求的收集、分發和處理,前後臺間數據的流轉、轉換、綁定。事實上,SpringMVC作爲一個完備的MVC框架還解決了異常處理、國際化和標籤庫等基本問題,此不贅述。
三. SpringMVC應用開發流程剖析:XML配置與註解配置
在我們熟悉了SpringMVC請求處理流程後,本節提供了一個入門案例來深入理解SpringMVC的請求處理流程,同時熟悉SpringMVC的應用開發流程。開發一個SpringMVC應用,首先需要爲我們的Web項目添加Spring支持,然後我們就可以採用基於XMl配置的方式或者基於註解配置方式進行應用的構建。本節將分別演示基於XML配置和Annotation配置的SpringMVC 應用。
1、SpringMVC應用開發流程DEMO:XML配置
(1). 在web.xml中配置前端控制器 DispatcherServlet
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>SpringMVCDemo</display-name>
<!-- 配置Spring MVC的前端控制器:DispatchcerServlet -->
<servlet>
<servlet-name>springmvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<!-- SpringMVC配置文件路徑和名稱設定 -->
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springmvc.xml</param-value>
</init-param>
<!-- Web應用啓動時立即加載 -->
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springmvc</servlet-name>
<url-pattern>/</url-pattern> <!-- 攔截所有請求 -->
</servlet-mapping>
</web-app>
要想把SpringMVC框架應用到Web項目中,我們首先需要在web.xml添加一個Servlet —— DispatchcerServlet。DispatcherServlet是SpringMVC的集中訪問點,其核心功能就是分發請求,而且能與Spring IoC容器無縫集成,從而可以獲得Spring的所有好處。
在配置DispatchcerServlet時,我們可以指定SpringMVC配置文件的路徑,以便DispatchcerServlet查找並根據文件配置信息創建一個WebApplicationContext容器對象,即上下文環境。特別需要注意的是,WebApplicationContext繼承自ApplicationContext容器,它的初始化方式和BeanFactory、ApplicationContext有所區別,因爲WebApplicationContext需要在Web容器環境下才能完成啓動Spring Web應用上下文的工作。在初始化WebApplicationContext容器後,開發者就可以很自然地使用Spring的IoC、AoP等特性了。
DispatcherServlet作爲Spring Web MVC的集中訪問點,需要在Web應用啓動時立即創建實例並初始化WebApplicationContext容器,因此在web.xml中將其設爲 load-on-startup Servlet。
(2). 在web.xml中指定路徑配置SpringMVC的配置文件
<?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-4.0.xsd">
<!-- 配置Handle,映射"/hello"請求 -->
<bean name="/hello" class="cn.edu.tju.rico.controller.HelloController"/>
<!-- 處理映射器將bean的name作爲url進行查找,需要在配置Handle時指定name(即url) -->
<bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/>
<!-- SimpleControllerHandlerAdapter是一個處理器適配器,所有處理適配器都要實現HandlerAdapter接口 -->
<bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"/>
<!-- 視圖解析器 -->
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"/>
</beans>
如果我們採用XML方式配置SpringMVC的Controller,那麼在配置文件中我們需要指定具體的Controller及其所處理的請求URI。至於HandlerMapping、HandlerAdapter和ViewResolver等SpringMVC核心組件可以顯式配置,也可以使用SpringMVC的默認配置。也就是說,上述關於HandlerMapping、HandlerAdapter和ViewResolver等核心組件的配置可以刪除。SpringMVC關於以上核心組件的默認配置在與DispatcherServlet同一目錄下面的DispatcherServlet.properties中,如下所示:
# Default implementation classes for DispatcherServlet's strategy interfaces.
# Used as fallback when no matching beans are found in the DispatcherServlet context.
# Not meant to be customized by application developers.
org.springframework.web.servlet.LocaleResolver=org.springframework.web.servlet.i18n.AcceptHeaderLocaleResolver
org.springframework.web.servlet.ThemeResolver=org.springframework.web.servlet.theme.FixedThemeResolver
# 兩個默認的HandlerMapping
org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping
# 三個默認的HandlerAdapter
org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter
# 三個默認的ExceptionResolver
org.springframework.web.servlet.HandlerExceptionResolver=org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerExceptionResolver,\
org.springframework.web.servlet.mvc.annotation.ResponseStatusExceptionResolver,\
org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver
org.springframework.web.servlet.RequestToViewNameTranslator=org.springframework.web.servlet.view.DefaultRequestToViewNameTranslator
# 一個默認的InternalResourceViewResolver
org.springframework.web.servlet.ViewResolver=org.springframework.web.servlet.view.InternalResourceViewResolver
org.springframework.web.servlet.FlashMapManager=org.springframework.web.servlet.support.SessionFlashMapManager
如果開發者在SpringMVC配置文件中沒有配置HandlerMapping、HandlerAdapter等組件,那麼DispatcherServlet會從上面的默認配置中選擇合適的實現類進行請求匹配、處理、響應等操作。
(3). 實現SpringMVC配置文件中配置的Controller
public class HelloController implements Controller{
public ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response) throws Exception {
//創建準備返回的ModelAndView對象,如名所示,該對象通常包含了返回視圖名、模型名稱以及模型對象
ModelAndView mv = new ModelAndView();
//添加模型數據,可以是任意的POJO對象
mv.addObject("message", "Hello, Rico...");
// 設置邏輯視圖名,視圖解析器會根據該名字解析到具體的視圖頁面
mv.setViewName("/WEB-INF/views/welcome.jsp");
// 返回ModelAndView對象
return mv;
}
}
如果我們採用XML方式配置SpringMVC的Controller,那麼我們具體的Controller必須Controller接口,並在handleRequest方法中調用業務邏輯組件去處理請求並生成響應。這裏的響應是一個ModelAndView對象,DispatcherServlet會選擇合適的ViewResolver並根據ModelAndView對象把Model填充到View中進行渲染然後返回給用戶。
注意到,Controller接口的實現類只能處理一個單一的請求動作,也就是說,一個Controller對應一個請求。稍後我們提到的基於註解的控制器可以支持同時處理多個請求動作,真正實現方法級別的請求攔截和處理。
(4). 相應的視圖頁面
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<base href="<%=basePath%>">
<title>welcome</title>
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">
<meta http-equiv="keywords" content="keyword1,keyword2,keyword3">
<meta http-equiv="description" content="This is my page">
</head>
<body>
${requestScope.message} <br>
</body>
</html>
在上面的視圖中,DispatcherServlet會選擇合適的ViewResolver並根據Controller返回的Model填充到View中展現給用戶,如下圖所示:
2、SpringMVC應用開發流程DEMO:Annotation 配置
(1). 在web.xml中配置前端控制器 DispatcherServlet
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>SpringMVCDemo</display-name>
<!-- 配置Spring MVC的前端控制器:DispatchcerServlet -->
<servlet>
<servlet-name>springmvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<!-- SpringMVC配置文件路徑和名稱設定 -->
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:springmvc.xml</param-value>
</init-param>
<!-- Web應用啓動時立即加載 -->
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>springmvc</servlet-name>
<url-pattern>/</url-pattern> <!-- 攔截所有請求 -->
</servlet-mapping>
</web-app>
DispatcherServlet的配置與基於XML配置的SpringMVC無異,此不贅述。
(2). 在web.xml中指定路徑配置SpringMVC的配置文件
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.0.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-4.0.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc-4.0.xsd">
<!-- 配置Handle,映射"/hello"請求 -->
<!-- <bean name="/hello" class="cn.edu.tju.rico.controller.HelloController"/> -->
<!-- Spring自動掃描相關類並將Spring註解類註冊爲Spring的Bean -->
<context:component-scan base-package="cn.edu.tju.rico"></context:component-scan>
<!-- 處理映射器將bean的name作爲url進行查找,需要在配置Handle時指定name(即url) -->
<!-- <bean class="org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping"/> -->
<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping"/>
<!-- SimpleControllerHandlerAdapter是一個處理器適配器,所有處理適配器都要實現HandlerAdapter接口 -->
<!-- <bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter"/> -->
<bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"/>
<!-- 視圖解析器 -->
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver"/>
</beans>
如果我們採用Annotation方式配置SpringMVC的Controller,那麼在配置文件中首先需要掃描SpringMVC應用中所有基於註解的控制器類。注意到,關於HandlerMapping、HandlerAdapter的配置我們分別使用的是RequestMappingHandlerMapping和RequestMappingHandlerAdapter兩個實現類,而沒有使用SpringMVC默認配置中對應的註解類:DefaultAnnotationHandlerMapping 和 AnnotationMethodHandlerAdapter,這是因爲DefaultAnnotationHandlerMapping 和 AnnotationMethodHandlerAdapter這兩個類已被Spring廢棄。
(3). 實現 Controller
@Controller
public class HelloControllerByAnnotation {
@RequestMapping("/hello")
public ModelAndView hello() {
// 創建準備返回的ModelAndView對象,如名所示,該對象通常包含了返回視圖名、模型名稱以及模型對象
ModelAndView mv = new ModelAndView();
// 添加模型數據,可以是任意的POJO對象
mv.addObject("message", "Hello, Rico~");
// 設置邏輯視圖名,視圖解析器會根據該名字解析到具體的視圖頁面
mv.setViewName("/WEB-INF/views/welcome.jsp");
// 返回ModelAndView對象
return mv;
}
}
如果我們採用Annotation方式配置SpringMVC的Controller,那麼我們需要使用註解@Controller標明具體的Controller並使用註解@RequestMapping爲特定的請求綁定處理方法,如上所示。這樣,我們只需在hello()方法中調用業務邏輯組件去處理請求並生成響應即可。這裏的響應可以是一個ModelAndView對象,也可以是一個字符串(邏輯視圖名),還可以是一個Map等,甚至可以什麼都不返回。
注意到,與Controller接口的實現類只能處理一個單一的請求動作不同的是,基於註解的控制器可以支持同時處理多個請求動作,真正實現了方法級別的請求攔截和處理。
(4). 開發相應的視圖頁面
<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>
<%
String path = request.getContextPath();
String basePath = request.getScheme()+"://"+request.getServerName()+":"+request.getServerPort()+path+"/";
%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<base href="<%=basePath%>">
<title>welcome</title>
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">
<meta http-equiv="keywords" content="keyword1,keyword2,keyword3">
<meta http-equiv="description" content="This is my page">
</head>
<body>
${requestScope.message} <br>
</body>
</html>
在上面的視圖中,DispatcherServlet會選擇合適的ViewResolver並根據Controller返回的Model填充到View中展現給用戶,如下圖所示:
3、注意
(1). HandlerMapping和HandlerAdapter的實現RequestMappingHandlerMapping和RequestMappingHandlerAdapter提供了請求信息的轉換(讀寫XML、讀寫JSON)、數據轉換、數據格式化以及數據校驗等支持,我們可以在SpringMVC配置文件中通過以下方式添加:
<!-- 設置配置方案 -->
<mvc:annotation-driven/>1212
(2). 當我們(顯式/隱式)請求靜態資源(包括圖片、js等文件)時,由於在web.xml中使用了DispatcherServlet來攔截所有請求,這時DispatcherServlet會將“/”看成請求路徑,從而導致因找不到這些靜態文件而報404錯誤。我們可以在SpringMVC配置文件中通過以下方式來使用默認的Servlet來響應靜態文件:
<!-- 使用默認的Servlet來響應靜態文件 -->
<mvc:default-servlet-handler/>1212
四、SpringMVC 數據綁定機制的應用:使用註解完成請求參數綁定
我們知道,在SpringMVC中使用註解方式處理請求時,我們可以通過一系列註解輕鬆地將請求參數映射(綁定)到Handler(Controller)中對應的請求處理方法的參數中,其底層就是由我們在第二節中介紹的SpringMVC數據綁定機制支持的。本節將介紹參數綁定常用註解,並根據它們處理的Request的不同內容分爲四類:
功能 | 註解 |
---|---|
處理Request URI 部分(這裏指URI Template中Variable,不含QueryString部分)的註解 | @PathVariable; |
處理Request Header部分的註解 | @RequestHeader, @CookieValue; |
處理Request Body部分的註解 | @RequestParam,@RequestBody; |
處理Attribute類型的註解 | @SessionAttributes, @ModelAttribute; |
此外,我們還介紹了處理Response的註解@ResponseBody,其與@RequestBody相對應。
1、@PathVariable
當使用@RequestMapping URI template 樣式映射時, 即 someUrl/{paramId}, 這時的paramId可通過 @Pathvariable註解綁定它傳過來的值到方法的參數上。
@Controller
@RequestMapping("/owners/{ownerId}")
public class RelativePathUriTemplateController {
@RequestMapping("/pets/{petId}")
public void findPet(@PathVariable String ownerId, @PathVariable String petId, Model model) {
// implementation omitted
}
}
上面代碼把URI template中變量ownerId的值和petId的值,綁定到方法的參數上。若方法參數名稱和需要綁定的uri template中變量名稱不一致,需要在@PathVariable(“name”)指定uri template中的名稱。
2、@RequestHeader,@CookieValue
(1). @RequestHeader
@RequestHeader 註解可以把Request請求header部分的值綁定到方法的參數上,如下所示 :
Request Header:
// 這是一個 Request 的 header 部分
Host localhost:8080
Accept text/html,application/xhtml+xml,application/xml;q=0.9
Accept-Language fr,en-gb;q=0.7,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 300
使用@RequestHeader註解獲取Request Header中的一些字段:
@RequestMapping("/displayHeaderInfo.do")
public void displayHeaderInfo(@RequestHeader("Accept-Encoding") String encoding,
@RequestHeader("Keep-Alive") long keepAlive) {
//...
}
上面的代碼將把request header部分的Accept-Encoding的值綁定到參數encoding上, 把Keep-Alive header的值綁定到參數keepAlive上。
(2). @CookieValue
@CookieValue 可以把Request header中關於cookie的值綁定到方法的參數上,例如有如下Cookie值:
JSESSIONID=415A4AC178C59DACE0B2C9CA727CDD84
通過下列方式就可以把JSESSIONID的值綁定到參數cookie上,如下:
@RequestMapping("/displayHeaderInfo.do")
public void displayHeaderInfo(@CookieValue("JSESSIONID") String cookie) {
//...
}
3、@RequestParam,@RequestBody,@ResponseBody
(1). @RequestParam
- 常用來處理簡單類型的綁定,通過Request.getParameter() 獲取的String可直接轉換爲簡單類型的情況( String–> 簡單類型的轉換操作由ConversionService配置的轉換器來完成);因爲其內部使用request.getParameter()方式獲取參數,所以可以處理get方式中queryString的值,也可以處理post方式中body data的值;
- 用來處理Content-Type: 爲 application/x-www-form-urlencoded編碼的內容,提交方式GET、POST;
@Controller
@RequestMapping("/pets")
@SessionAttributes("pet")
public class EditPetForm {
@RequestMapping(method = RequestMethod.GET)
public String setupForm(@RequestParam("petId") int petId, ModelMap model) {
Pet pet = this.clinic.loadPet(petId);
model.addAttribute("pet", pet);
return "petForm";
}
}
(2). @RequestBody
@RequestBody通過使用HandlerAdapter默認配置的HttpMessageConverters來解析Request請求的Body部分數據並將相應的數據綁定到Controller中方法的參數上,其常用來處理Content-Type不是application/x-www-form-urlencoded編碼的內容,例如application/json, application/xml等。注意,request的body部分的數據編碼格式由header部分的Content-Type指定。@RequestBody的具體使用場景如下:
1). GET、POST方式提時,根據 Request Header Content-Type 的值來判斷:
- application/x-www-form-urlencoded, 可選(即非必須,因爲這種情況的數據@RequestParam, @ModelAttribute也可以處理,當然@RequestBody也能處理);
- multipart/form-data, 不能處理(即使用@RequestBody不能處理這種格式的數據);
- 其他格式, 必須(其他格式包括application/json,application/xml等。這些格式的數據必須使用@RequestBody來處理);
2). PUT方式提交時,根據 Request Header Content-Typee 的值來判斷:
- application/x-www-form-urlencoded, 必須;
- multipart/form-data, 不能處理;
- 其他格式, 必須;
@RequestMapping(value = "/something", method = RequestMethod.PUT)
public void handle(@RequestBody String body, Writer writer) throws IOException {
writer.write(body);
}
(3). @ResponseBody
@ResponseBody註解用於將Controller的方法返回的對象通過適當的HttpMessageConverter轉換爲指定格式後,寫入到Response對象的body數據區,其在返回的數據不是html標籤的頁面,而是其他某種格式的數據時(如json、xml等)使用,例如:
@RequestMapping(value="/testRequestBody")
// 將Controller的方法返回的對象通過適當的消息轉換器轉換爲指定格式後寫入到Response對象的body數據區
@ResponseBody
public Book setJson(@RequestBody Book book,
HttpServletResponse response) throws Exception{
// @RequestBody根據json數據,轉換成對應的Object
book.setAuthor("肖文吉");
logger.info(JSONObject.toJSONString(book));
return book;
}
4、@SessionAttributes,@ModelAttribute
(1). @SessionAttributes
@SessionAttributes註解用來綁定HttpSession中的attribute對象的值,便於在方法中的參數裏使用,例如:
@Controller
@RequestMapping("/editPet.do")
@SessionAttributes("pet")
public class EditPetForm {
// ...
}
(2). @ModelAttribute
@ModelAttribute註解有兩個用法,一個是用於方法上,一個是用於參數上。用於方法上時,被其註釋的方法會在Controller每個方法執行前被執行,因此通常用來在處理@RequestMapping之前爲請求綁定需要從後臺查詢的model;用於參數上時,用來通過名稱對應把相應名稱的值綁定到註解的參數bean上,其中要綁定的值常常來源於:
- @SessionAttributes 啓用的attribute 對象上;
- @ModelAttribute 用於方法上時指定的model對象;
@ModelAttribute在方法上使用示例:
// Add one attribute
// The return value of the method is added to the model under the name "account"
// You can customize the name via @ModelAttribute("myAccount")
@ModelAttribute
public Account addAccount(@RequestParam String number) {
return accountManager.findAccount(number);
}
這種方式實際的效果就是在調用@RequestMapping的方法之前向request對象的model裏put(“account”, Account)。
@ModelAttribute用在參數上的示例代碼:
@RequestMapping(value="/owners/{ownerId}/pets/{petId}/edit", method = RequestMethod.POST)
public String processSubmit(@ModelAttribute Pet pet) {
}
首先查詢 @SessionAttributes有無綁定的Pet對象,若沒有則查詢@ModelAttribute方法層面上是否綁定了Pet對象,若沒有則將URI template中的值按對應的名稱綁定到Pet對象的各屬性上。
五、SpringMVC與Struts2間的區別
SpringMVC與Struts2是當今最爲流行的兩個Java Web MVC框架。在本文開頭,我們概述了MVC模式和框架並對MVC框架所應具有的一些基礎功能作了簡單的總結。本節,筆者將結合博友Java我人生《SpringMVC與Struts2區別與比較總結》一文從以下七個方面進一步總結SpringMVC與Struts2間的一些區別。
1、請求處理
Struts2是類級別的攔截,一個Action對應一個request上下文;而SpringMVC是方法級別的攔截,一個方法對應一個request上下文。特別地,在SpringMVC中,由於請求處理方法和URI對應,所以SpringMVC從架構上本身就很容易實現RESTful URL。相比而言,Struts2 則實現起來要相對費勁,因爲雖然Struts2中Action的一個方法可以對應一個URL,但是其類屬性卻被所有方法共享,這就導致無法用註解或其他方式標識請求處理方法了。
SpringMVC的方法之間基本上是獨立的,各個方法獨享Request、Response數據,並且請求數據通過參數獲取、處理結果通過ModelMap交回給框架,因此方法之間不共享變量;而Struts2就搞的就比較亂,雖然方法之間也是獨立的,但是一個Action對應一個request上下文(每次來了請求就創建一個Action),也就是說其所有Action變量是共享的,這雖然不會影響程序運行,但卻給我們編碼讀程序時帶來麻煩。
Struts2需要針對每個request進行封裝並把request,session等servlet生命週期的變量封裝成一個一個Map供給Action使用,同時保證線程安全,所以在原則上,是比較耗費內存的;而由於SpringMVC是方法級別的攔截,各個方法獨享Request、Response數據,因此本身就是線程安全的。
2、攔截器機制
- Struts2有自己的interceptor機制,SpringMVC用的是獨立的AOP方式,這樣導致Struts2的配置文件量還是比SpringMVC大。
3、集中訪問點
- SpringMVC的入口是servlet,而Struts2的入口是filter,這就導致了二者的機制不同,這裏就牽涉到Servlet和Filter的區別了。
4、對Ajax的支持
- SpringMVC集成了Ajax,使用非常方便,只需一個註解@ResponseBody就可以實現,然後直接返回響應文本即可
- Struts2攔截器集成了Ajax,在Action中處理時一般必須安裝插件或者自己寫代碼集成進去,使用起來也相對不方便
5、與Spring的整合
- Spring MVC可以和Spring無縫整合,在項目的管理和安全方面也比Struts2要好(當然Struts2也可以通過不同的目錄結構和相關配置做到SpringMVC一樣的效果,但是需要xml配置的地方不少);而Struts2需要專門的插件來完成對Spring的整合。
6、數據驗證
- SpringMVC驗證支持JSR303,處理起來相對更加靈活方便;而Struts2驗證比較繁瑣,感覺太煩亂。
7、配置和效率
- SpringMVC開發效率和性能高於Struts2 (ps : 個人覺得性能應該是差不多的),並且SpringMVC可以認爲是100%零配置。
引用
SpringMvc之參數綁定註解詳解
SpringMVC源碼剖析(五)-消息轉換器HttpMessageConver
SpringMVC源碼總結(一)HandlerMapping和HandlerAdapter入門
SpringMVC與Struts2區別與比較總結
第三章 DispatcherServlet詳解 ——跟開濤學SpringMVC
本文原創作者:書呆子Rico
作者博客地址:http://blog.csdn.net/justloveyou_/