轉載說明:infoQ就是牛人多,看人家去年就把Spring2.5注視驅動的MVC寫出來了,還是這么詳細,我真是自嘆不如,今天偶爾看到這篇文章非常認真的拜讀了2遍,簡直是茅廁頓開啊....\(^o^)/~<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

PS:如果各位看客覺得這篇文章看不太懂,千萬別著急,我自己曾經寫了兩篇比較基礎的,您可以先看看我寫的那兩篇之后再看這篇,就會有很多收獲..

廣告時間:~\(≧▽≦)/~

Spring2.5注釋驅動與基于注釋的MVC

Spring2.5注釋語法(上)——Spring2.5注釋驅動的IoC

?

本文轉載自Spring 2.5：Spring MVC中的新特性

?

Spring框架從創建伊始就致力于為復雜問題提供強大的、非侵入性的解決方案。Spring 2.0當中為縮減XML配置文件數量引入定制命名空間功能，從此它便深深植根于核心Spring框架（aop、context、jee、jms、 lang、tx和util命名空間）、Spring Portfolio項目（例如Spring Security）和非Spring項目中（例如CXF）。

Spring 2.5推出了一整套注解，作為基于XML的配置的替換方案。注解可用于Spring管理對象的自動發現、依賴注入、生命周期方法、Web層配置和單元/集成測試。

探索Spring 2.5中引入的注解技術系列文章由三部分組成，本文是其中的第二篇，它主要講述了Web層中的注解支持。最后一篇文章將著重介紹可用于集成和測試的其它特性。

這個系列文章的第一部分論述了Java注解（annotation）是如何代替XML來配置Spring管理對象和依賴注入的。我們再用一個例子回顧一下：

@Controller
public class ClinicController {

??? private final Clinic clinic;

??? @Autowired
??? public ClinicController(Clinic clinic) {
?????? this.clinic = clinic;
??? }
??? ...

@Controller表明ClinicController是Web層組件，@Autowired請求一個被依賴注入的Clinic實例。這個例子只需要少量的XML語句就能使容器識別兩個注解，并限定組件的掃描范圍：

<context:component-scan base-package="org.springframework.samples.petclinic"/>

這對Web層可謂是個福音，因為在這層Spring的XML配置文件已日益臃腫，甚至可能還不如層下的配置來得有用。控制器掌握著許多屬性，例如視圖名稱、表單對象名稱和驗證器類型，這些多是關乎配置的，甚少關于依賴注入的。通過bean定義繼承，或者避免配置變化不是很頻繁的屬性，也可以有效的管理類似的配置。不過以我的經驗，很多開發人員都不會這樣做，結果就是XML文件總比實際需要的要龐大。不過 @Controller和@Autowired對Web層的配置會產生積極的作用。

在系列文章的第二部分我們將繼續討論這個問題，并瀏覽Spring 2.5在Web層的注解技術。這些注解被非正式的稱為@MVC，它涉及到了Spring MVC和Spring Porlet MVC，實際上本文討論的大部分功能都可以應用在這兩個框架上。

從Controller到@Controller

與第一部分討論的注解相比，@MVC已不只是作為配置的一種替換方案這樣簡單了，考慮下面這個著名的Spring MVC控制器簽名：

public interface Controller {
??? ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse
response) throws Exception;
}

所有的Spring MVC控制器要么直接實現Controller接口，要么就得擴展類似AbstractController、 SimpleFormController、 MultiActionController或AbstractWizardFormController這樣的基類實現。正是Controller接口允許Spring MVC的DispatcherServlet把所有上述對象都看作是“處理器（handlers）”，并在一個名為 SimpleControllerHandlerAdapter的適配器的幫助下調用它們。

@MVC從三個重要的方面改變了這個程序設計模型：

不需要任何接口或者基類。

允許有任意數量的請求處理方法。

在方法簽名上具有高度的靈活性。

考慮到以上三個要點，就可以說很公平的說@MVC不僅僅是個替換方案了，它將會是Spring MVC的控制器技術演變過程中下一個重要步驟。

DispatcherServlet在名為AnnotationMethodHandlerAdapter的適配器幫助下調用被注解的控制器。正是這個適配器做了大量工作支持我們此后將會討論的注解，同時也是它有效的取代了對于控制器基類的需求。

@RequestMapping簡介

我們還是從一個類似于傳統的Spring MVC Controller控制器開始：

@Controller
public class AccountsController {

??? private AccountRepository accountRepository;

??? @Autowired
??? public AccountsController(AccountRepository accountRepository) {
?????? this.accountRepository = accountRepository;
??? }

??? @RequestMapping("/accounts/show")
??? public ModelAndView show(HttpServletRequest request,
???????????????????????????? HttpServletResponse response) throws Exception {
?????? String number = ServletRequestUtils.getStringParameter(request, "number");
?????? ModelAndView mav = new ModelAndView("/WEB-INF/views/accounts/show.jsp");
?????? mav.addObject("account", accountRepository.findAccount(number));
?????? return mav;
??? }
}

此處與以往的不同在于，這個控制器并沒有擴展Controller接口，并且它用@RequestMapping注解指明show()是映射到URI路徑 “/accounts/show”的請求處理方法。除此以外，其余代碼都是一個典型的Spring MVC控制器應有的內容。

在將上述的方法完全轉化到@MVC后，我們會再回過頭來看@RequestMapping，但是在此之前還有一點需要提請注意，上面的請求映射URI也可匹配帶有任意擴展名的URI路徑，例如：

/accounts/show.htm
/accounts/show.xls
/accounts/show.pdf
...

靈活的請求處理方法簽名

我們曾經承諾過要提供靈活的方法簽名，現在來看一下成果。輸入的參數中移除了響應對象，增加了一個代表模型的Map；返回的不再是ModelAndView，而是一個字符串，指明呈現響應時要用的視圖名字：

@RequestMapping("/accounts/show")
public String show(HttpServletRequest request, Map<String, Object> model)
throws Exception {
??? String number = ServletRequestUtils.getStringParameter(request, "number");
??? model.put("account", accountRepository.findAccount(number));
??? return "/WEB-INF/views/accounts/show.jsp";
}

Map輸入參數是一個“隱式的”模型，對于我們來說在調用方法前創建它很方便，其中添加的鍵—值對數據便于在視圖中解析應用。本例視圖為show.jsp頁面。

@MVC可以接受多種類型的輸入參數，例如 HttpServletRequest/HttpServletResponse、HttpSession、Locale、InputStream、 OutputStream、File[]等等，它們的順序不受任何限制；同樣它也允許多種返回類型，例如ModelAndView、Map、 String，或者什么都不返回。你可以查看@RequestMapping的JavaDoc以了解它支持的所有輸入和返回參數類型。

有種令人感興趣的情形是當方法沒有指定視圖時（例如返回類型為void）會有什么事情發生，按照慣例DispatcherServlet要再使用請求URI的路徑信息，不過要移去前面的斜杠和擴展名。讓我們把返回類型改為void：

@RequestMapping("/accounts/show")
public void show(HttpServletRequest request, Map<String, Object> model) throws Exception {
??? String number = ServletRequestUtils.getStringParameter(request, "number");
??? model.put("account", accountRepository.findAccount(number));
}

對于給定的請求處理方法和“/accounts/show”的請求映射，我們可以期望DispatcherServlet能夠獲得“accounts/show”的默認視圖名稱，當它與如下適當的視圖解析器結合共同作用時，會產生與前面指明返回視圖名同樣的結果：

<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
??? <property name="prefix" value="/WEB-INF/views/" />
??? <property name="suffix" value=".jsp" />
</bean>

強烈推薦視圖名稱依賴慣例的方式，因為這樣可以從控制器代碼中消除硬編碼的視圖名稱。如果你想定制 DispatcherServlet獲取默認視圖名的方式，就在servlet上下文環境中配置一個你自己的 RequestToViewNameTranslator實現，并為其bean id賦名為“viewNameTranslator”。

用@RequestParam提取和解析參數

@MVC另外一個特性是其提取和解析請求參數的能力。讓我們繼續重構上面的方法，并在其中添加@RequestParam注解：

@RequestMapping("/accounts/show")
public void show(@RequestParam("number") String number, Map<String, Object> model) {
??? model.put("account", accountRepository.findAccount(number));
}

這里@RequestParam注解可以用來提取名為“number”的String類型的參數，并將之作為輸入參數傳入。 @RequestParam支持類型轉換，還有必需和可選參數。類型轉換目前支持所有的基本Java類型，你可通過定制的PropertyEditors 來擴展它的范圍。下面是一些例子，其中包括了必需和可選參數：

@RequestParam(value="number", required=false) String number
@RequestParam("id") Long id
@RequestParam("balance") double balance
@RequestParam double amount

注意，最后一個例子沒有提供清晰的參數名。當且僅當代碼帶調試符號編譯時，結果會提取名為“amount ”的參數，否則，將拋出IllegalStateException異常，因為當前的信息不足以從請求中提取參數。由于這個原因，在編碼時最好顯式的指定參數名。

繼續@RequestMapping的討論

把@RequestMapping放在類級別上是合法的，這可令它與方法級別上的@RequestMapping注解協同工作，取得縮小選擇范圍的效果，下面是一些例子。

類級別：

RequestMapping("/accounts/*")

方法級別：

@RequestMapping(value="delete", method=RequestMethod.POST)
@RequestMapping(value="index", method=RequestMethod.GET, params="type=checking")
@RequestMapping

第一個方法級的請求映射和類級別的映射結合，當HTTP方法是POST時與路徑“/accounts/delete”匹配；第二個添加了一個要求，就是名為“type”的請求參數和其值“checking”都需要在請求中出現；第三個根本就沒有指定路徑，這個方法匹配所有的 HTTP方法，如果有必要的話可以用它的方法名。下面改寫我們的方法，使它可以依靠方法名進行匹配，程序如下：

@Controller
@RequestMapping("/accounts/*")
public class AccountsController {

??? @RequestMapping(method=RequestMethod.GET)
??? public void show(@RequestParam("number") String number, Map<String, Object> model)
?? {
?????? model.put("account", accountRepository.findAccount(number));
??? }
??? ...

方法匹配的請求是“/accounts/show”，依據的是類級別的@RequestMapping指定的匹配路徑“/accounts/*”和方法名“show”。

消除類級別的請求映射

Web層注解頻遭詬病是有事實依據的，那就是嵌入源代碼的URI路徑。這個問題很好矯正，URI路徑和控制器類之間的匹配關系用XML配置文件去管理，只在方法級的映射中使用@RequestMapping注解。

我們將配置一個ControllerClassNameHandlerMapping，它使用依賴控制器類名字的慣例，將URI映射到控制器：

<bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/>

現在“/accounts/*”這樣的請求都被匹配到AccountsController上，它與方法級別上的@RequestMapping注解協作的很好，只要添加上方法名就能夠完成上述映射。此外，既然我們的方法并不會返回視圖名稱，我們現在就可以依據慣例匹配類名、方法名、URI路徑和視圖名。

當@Controller被完全轉換為@MVC后，程序的寫法如下：

@Controller
public class AccountsController {

???? private AccountRepository accountRepository;

???? @Autowired
??? public AccountsController(AccountRepository accountRepository) {
?????? this.accountRepository = accountRepository;
??? }

???? @RequestMapping(method=RequestMethod.GET)
??? public void show(@RequestParam("number") String number, Map<String, Object> model)
?? {
?????? model.put("account", accountRepository.findAccount(number));
??? }
??? ...

對應的XML配置文件如下：

<context:component-scan base-package="com.abc.accounts"/>

? <bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/>

? <bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
??? <property name="prefix" value="/WEB-INF/views/" />
??? <property name="suffix" value=".jsp" />
</bean>

你可以看出這是一個最精減的XML。程序里注解中沒有嵌入URI路徑，也沒有顯式指定視圖名，請求處理方法也只有很簡單的一行，方法簽名與我們的需求精準匹配，其它的請求處理方法也很容易添加。不需要基類，也不需要XML（至少也是沒有直接配置控制器），我們就能獲得上述所有優勢。

也許接下來你就可以看到，這種程序設計模型是多么有效了。

@MVC表單處理

一個典型的表單處理場景包括：獲得可編輯對象，在編輯模式下顯示它持有的數據、允許用戶提交并最終進行驗證和保存變化數據。Spring MVC提供下列幾個特性輔助進行上述所有活動：數據綁定機制，完全用從請求參數中獲得的數據填充一個對象；支持錯誤處理和驗證；JSP表單標記庫；基類控制器。使用@MVC，除了由于@ModelAttribute、@InitBinder和@SessionAttributes這些注解的存在而不再需要基類控制器外，其它一切都不需要改變。

@ModelAttribute注解

看一下這些請求處理方法簽名：

@RequestMapping(method=RequestMethod.GET)
public Account setupForm() {
??? ...
}

? @RequestMapping(method=RequestMethod.POST)
public void onSubmit(Account account) {
??? ...
}

它們是非常有效的請求處理方法簽名。第一個方法處理初始的HTTP GET請求，準備被編輯的數據，返回一個Account對象供Spring MVC表單標簽使用。第二個方法在用戶提交更改時處理隨后的HTTP POST請求，并接收一個Account對象作為輸入參數，它是Spring MVC的數據綁定機制用請求中的參數自動填充的。這是一個非常簡單的程序模型。

Account對象中含有要被編輯的數據。在Spring MVC的術語當中，Account被稱作是表單模型對象。這個對象必須通過某個名稱讓表單標簽（還有數據綁定機制）知道它的存在。下面是從JSP頁面中截取的部分代碼，引用了一個名為“account”的表單模型對象：

<form:form modelAttribute="account" method="post">

??? Account Number: <form:input path="number"/><form:errors path="number"/>
??? ...
?</form>

即使我們沒有在任何地方指定“account”的名稱，這段JSP程序也會和上面所講的方法簽名協作的很好。這是因為@MVC用返回對象的類型名稱作為默認值，因此一個Account類型的對象默認的就對應一個名為“account”的表單模型對象。如果默認的不合適，我們就可以用 @ModelAttribute來改變它的名稱，如下所示：

@RequestMapping(method=RequestMethod.GET)
public @ModelAttribute("account") SpecialAccount setupForm() {
??? ...
}
? @RequestMapping(method=RequestMethod.POST)
public void update(@ModelAttribute("account") SpecialAccount account) {
??? ...
}

@ModelAttribute同樣也可放在方法級的位置上，取得的效果稍有不同：

@ModelAttribute
public Account setupModelAttribute() {
??? ...
}

此處setupModelAttribute()不是一個請求處理方法，而是任何請求處理方法被調用之前，用來準備表單項模型對象的一個方法。對那些熟悉 Spring MVC的老用戶來說，這和SimpleFormController的formBackingObject()方法是非常相似的。

最初的GET方法中我們得到一次表單模型對象，在隨后的POST方法中當我們依靠數據綁定機制用用戶所做的改變覆蓋已有的Account對象時，我們會第二次得到它，在這種表單處理場景中把@ModelAttribute放在方法上是很有用的。當然，作為一種兩次獲得對象的替換方案，我們也可以在兩次請求過程中將它保存進HTTP的會話（session），這就是我們下面將要分析的情況。

用@SessionAttributes存儲屬性

@SessionAttributes注解可以用來指定請求過程中要放進session中的表單模型對象的名稱或類型，下面是一些例子：

@Controller
@SessionAttributes("account")
public class AccountFormController {
??? ...
}

? @Controller
@SessionAttributes(types = Account.class)
public class AccountFormController {
??? ...
}

根據上面的注解，AccountFormController會在初始的GET方法和隨后的POST方法之間，把名為 “account”的表單模型對象（或者象第二個例子中的那樣，把所有Account類型的表單模型對象）存入HTTP會話（session）中。不過，當有改變連續發生的時候，就應當把屬性對象從會話中移除了。我們可以借助SessionStatus實例來做這件事，如果把它添加進onSubmit的方法簽名中，@MVC會完成這個任務：

@RequestMapping(method=RequestMethod.POST)
public void onSubmit(Account account, SessionStatus sessionStatus) {
??? ...
??? sessionStatus.setComplete(); // Clears @SessionAttributes
}

定制數據綁定

有時數據綁定需要定制，例如我們也許需要指定必需填寫的域，或者需要為日期、貨幣金額等類似事情注冊定制的PropertyEditors。用@MVC實現這些功能是非常容易的：

@InitBinder
public void initDataBinder(WebDataBinder binder) {
??? binder.setRequiredFields(new String[] {"number", "name"});
}

@InitBinder注解的方法可以訪問@MVC用來綁定請求參數的DataBinder實例，它允許我們為每個控制器定制必須項。

數據綁定結果和驗證

數據綁定也許會導致類似于類型轉換或域缺失的錯誤。不管發生什么錯誤，我們都希望能返回到編輯的表單，讓用戶自行更正。要想實現這個目的，我們可直接在方法簽名的表單模型對象后面追加一個BindingResult對象，例程如下：

@RequestMapping(method=RequestMethod.POST)
public ModelAndView onSubmit(Account account, BindingResult bindingResult) {
??? if (bindingResult.hasErrors()) {
?????? ModelAndView mav = new ModelAndView();
?????? mav.getModel().putAll(bindingResult.getModel());
?????? return mav;
??? }
??? // Save the changes and redirect to the next view...
}

發生錯誤時我們返回到出現問題的視圖，并把從BindingResult得到的屬性增加到模型上，這樣特定域的錯誤就能夠反饋給用戶。要注意的是，我們并沒有指定一個顯式的視圖名，而是允許DispatcherServlet依靠與入口URI路徑信息匹配的默認視圖名。

調用Validator對象并把BindingResult傳給它，僅這一行代碼就可實現驗證操作。這允許我們在一個地方收集綁定和驗證錯誤：

@RequestMapping(method=RequestMethod.POST)
public ModelAndView onSubmit(Account account, BindingResult bindingResult) {
??? accountValidator.validate(account, bindingResult);
??? if (bindingResult.hasErrors()) {
?????? ModelAndView mav = new ModelAndView();
?????? mav.getModel().putAll(bindingResult.getModel());
?????? return mav;
??? }
??? // Save the changes and redirect to the next view...
}

現在是時候結束我們的Spring 2.5 Web層注解（非正式稱法為@MVC）之旅了。

總結

Web層的注解已經證明是相當有用的，不僅是因為它能夠大大減少XML配置文件的數量，而且還在于它能成就一個可自由訪問 Spring MVC控制器技術的精致、靈活和簡潔的程序設計模型。我們強烈推薦使用“慣例優先原則（convention-over-configuration）” 特性，以及以處理器映射為中心的策略給控制器派發請求，避免在源碼中嵌入URI路徑或是定義顯式的視圖名引用。

最后是本文沒有討論，但值得關注的一些非常重要的Spring MVC擴展。最新發布的Spring Web Flow版本2添加了一些特性，例如基于JSF視圖的Spring MVC、Spring的JavaScript庫，還有支持更先進編輯場景的高級狀態和導航管理。

?

轉載于:https://blog.51cto.com/tonyaction/190071

總結

以上是生活随笔為你收集整理的Spring 2.5：Spring MVC中的新特性的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。