将web請求映射到spring控制器 綁定form參數 驗證表單送出的參數
對于很多java程式員來說，他們的主要工作就是開發web應用，如果你也在做這樣的工作，那麼你一定會了解到建構這類系統所面臨的挑戰，例如狀态管理、工作流和參數驗證等。http協定的無狀态性使得這些任務極具挑戰性。
spring的web架構用于解決上述提到的問題，基于model-view-controller（mvc）模型，spring mvc可以幫助開發人員建構靈活易擴充的web
應用。
這一章将涉及spring mvc架構的主要知識，由于基于注解開發是目前spring社群的潮流，是以我們将側重介紹如何使用注解建立控制器，進而處理各類web請求和表單送出。在深入介紹各個專題之前，首先從一個比較高的層面觀察和了解下spring mvc的工作原理。
使用者每次點選浏覽器界面的一個按鈕，都發出一個web請求（request）。一個web請求的工作就像一個快遞員，負責将資訊從一個地方運送到另一個地方。
從web請求離開浏覽器（1）到傳回響應，中間經曆了幾個節點，在每個節點都進行一些操作用于交換資訊。下圖展示了spring mvc應用中web請求會遇到的幾個節點。
web請求經過幾個節點處理然後産生響應資訊
請求旅行的第一站是spring的dispatcherservlet，和大多數javaweb應用相同，spring mvc通過一個單獨的前端控制器過濾分發請求。當web應用委托一個servlet将請求分發給應用的其他元件時，這個servlert稱為前端控制器（front controller）。在spring mvc中，dispatcherservlet就是前端控制器。
dispatcherservlet的任務是将請求發送給某個spring控制器。控制器（controller）是spring應用中處理請求的元件。一般在一個應用中會有多個控制器，dispatcherservlet來決定把請求發給哪個控制器處理。dispatcherservlet會維護一個或者多個處理器映射（2），用于指出request的下一站——根據請求攜帶的url做決定。
一旦選好了控制器，dispatcherservlet會把請求發送給指定的控制器（3），控制器中的處理方法負責從請求中取得使用者送出的資訊，然後委托給對應的業務邏輯元件（service objects）處理。
控制器的處理結果包含一些需要傳回給使用者或者顯示在浏覽器中的資訊。這些資訊存放在模型（model）中，但是直接把原始資訊傳回給使用者非常低效——最好格式化成使用者友好的格式，例如html或者json格式。為了生成html格式的檔案，需要把這些資訊傳給指定的視圖（view），一般而言是jsp。
控制器的最後一個任務就是将資料打包在模型中，然後指定一個視圖的邏輯名稱（由該視圖名稱解析html格式的輸出），然後将請求和模型、視圖名稱一起發送回dispatcherservlet（4）。
注意，控制器并不負責指定具體的視圖，傳回給dispatcherservlet的視圖名稱也不會指定具體的jsp頁面（或者其他類型的頁面）；控制器傳回的僅僅是視圖的邏輯名稱，dispatcherservlet用這個名稱查找對應的視圖解析器（5），負責将邏輯名稱轉換成對應的頁面實作，可能是jsp也可能不是。
現在dispatcherservlet就已經知道将由哪個視圖渲染結果，至此一個請求的處理就基本完成了。最後一步就是視圖的實作（6），最經典的是jsp。視圖會使用模型資料填充到視圖實作中，然後将結果放在http響應對象中（7）。
如上一小節的圖展示的，看起來需要填寫很多配置資訊。幸運地是，spring的最新版本提供了很多容易配置的選項，降低了spring mvc的學習門檻。這裡我們先簡單配置一個spring mvc應用，作為這一章将會不斷完善的例子。
dispatcherservlet是spring mvc的核心，每當應用接受一個http請求，由dispatcherservlet負責将請求分發給應用的其他元件。
在舊版本中，dispatcherservlet之類的servlet一般在web.xml檔案中配置，該檔案一般會打包進最後的war包種；但是spring 3引入了注解，我們在這一章将展示如何基于注解配置spring mvc。
既然不适用web.xml檔案，你需要在servlet容器中使用java配置dispatcherservlet，具體的代碼列舉如下：
spitter這個單詞是我們應用的名稱，spittrwebappinitializer類是整個應用的總配置類。
abstractannotationconfigdispatcherservletinitializer這個類負責配置dispatcherservlet、初始化spring mvc容器和spring容器。getrootconfigclasses()方法用于擷取spring應用容器的配置檔案，這裡我們給定預先定義的rootconfig.class；getservletconfigclasses負責擷取spring mvc應用容器，這裡傳入預先定義好的webconfig.class；getservletmappings()方法負責指定需要由dispatcherservlet映射的路徑，這裡給定的是"/"，意思是由dispatcherservlet處理所有向該應用發起的請求。
當dispatcherservlet啟動時，會建立一個spring mvc應用容器并開始加載配置檔案中定義好的beans。通過getservletconfigclasses()方法，可以擷取由dispatcherservlet加載的定義在webconfig.class中的beans。
在spring web應用中，還有另一個spring應用容器，這個容器由contextloaderlistener建立。
我們希望dispatcherservlet僅加載web元件之類的beans，例如controllers（控制器）、view resolvers（視圖解析器）和處理器映射（handler mappings）；而希望contextloaderlistener加載應用中的其他類型的beans——例如業務邏輯元件、資料庫操作元件等等。
實際上，abstractannotationconfigdispatcherservletinitializer建立了dispatcherservlet和contextloaderlistener：getservletconfigclasses()傳回的配置類定義了spring mvc應用容器中的beans；getrootconfigclasses()傳回的配置類定義了spring應用根容器中的beans。【書中沒有說的】：spring mvc容器是根容器的子容器，子容器可以看到根容器中定義的beans，反之不行。
注意：通過abstractannotationconfigdispatcherservletinitializer配置dispatcherservlet僅僅是傳統的web.xml檔案方式的另一個可選項。盡管你也可以使用abstractannotationconfigdispatcherservletinitializer的一個子類引入web.xml檔案來配置，但這沒有必要。
這種方式配置dispatcherservlet需要支援servlert 3.0的容器，例如apache tomcat 7或者更高版本的。
正如可以通過多種方式配置dispatcherservlet一樣，也可以通過多種方式啟動spring mvc特性。原來我們一般在xml檔案中使用<mvc:annotation-driven>元素啟動注解驅動的spring mvc特性。
這裡我們仍然使用javaconfig配置，最簡單的spring mvc配置類代碼如下：
@configuration表示這是java配置類；@enablewebmvc注解用于啟動spring mvc特性。
僅僅這些代碼就可以啟動spring mvc了，雖然它換缺了一些必要的元件：
沒有配置視圖解析器。這種情況下，spring會使用beannameviewresolver，這個視圖解析器通過查找id與邏輯視圖名稱比對且實作了view接口的beans。
沒有啟動component-scanning。
dispatcherservlet作為預設的servlet，将負責處理所有的請求，包括對靜态資源的請求，例如圖檔和css檔案等。
是以，我們還需要在配置檔案中增加一些配置，使得這個應用可以完成最簡單的功能，代碼如下：
首先，通過@componentscan("org.test.spittr.web")注解指定bean的自動發現機制作用的範圍，待會會看到，被@controller等注解修飾的web的bean将被發現并加載到spring mvc應用容器。這樣就不需要在配置類中顯式定義任何控制器bean了。
然後，你通過@bean注解添加一個viewresolverbean，具體來說是internalresourceviewresolver。後面我們會專門探讨視圖解析器，這裡的三個函數的含義依次是：setprefix()方法用于設定視圖路徑的字首；setsuffix()用于設定視圖路徑的字尾，即如果給定一個邏輯視圖名稱——"home"，則會被解析成"/web-inf/views/home.jsp"； setexposecontextbeansasattributes(true)使得可以在jsp頁面中通過${ }通路容器中的bean。
這裡需要注意靜态路徑的設定，目前我的項目目錄如下：
項目目錄
最後，webconfig繼承了webmvcconfigureradapter類，然後覆寫了其提供的configuredefaultservlethandling()方法，通過調用configer.enable()，dispatcherservlet将會把針對靜态資源的請求轉交給servlert容器的default servlet處理。
rootconfig的配置就非常簡單了，唯一需要注意的是，它在設定掃描機制的時候，将之前webconfig設定過的那個包排除了；也就是說，這兩個掃描機制作用的範圍正交。rootconfig的代碼如下：
這一章要用的例子應用，從twitter擷取了一些靈感，是以最開始叫spitter；然後又借鑒了最近比較流行的網站flickr，是以我們也把e去掉，最終形成spittr這個名字。這也有利于區分領域名稱（類似于twitter，這裡用spring實作，是以叫spitter）和應用名稱。
spittr應用有兩個關鍵的領域概念：spitters（應用的使用者）和spittles（使用者釋出的狀态更新）。在這一章中，将專注于建構該應用的web層，建立控制器和顯示spittles，以及處理使用者注冊的表單。
基礎已經打好了，你已經配置好了dispatcherservlet，啟動了spring mvc特性等，接下來看看如何編寫spring mvc控制器。
在spring mvc應用中，控制器類就是含有被@requestmapping注解修飾的方法的類，其中該注解用于指出這些方法要處理的請求類型。
我們從最簡單的請求"/"開始，用于渲染該應用的首頁，homecontroller的代碼列舉如下：
@controller是一個模式化的注解，它的作用跟@component一樣；component-scanning機制會自動發現該控制器，并在spring容器中建立對應的bean。
根據之前配置的internalresourceviewresolver，最後解析成/web-inf/views/home.jsp，home.jsp的内容列舉如下：
welcom to spittr
控制器的測試通過mockito架構進行，首先在pom檔案中引入需要的依賴庫：
然後，對應的單元測試用例homecontrollertest的代碼如下所示：
首先stanalonesetup()方法通過homecontroller的執行個體模拟出一個web服務，然後使用perform執行對應的get請求，并檢查傳回的視圖的名稱。mockmvcbuilders類有兩個靜态接口，代表兩種模拟web服務的方式：獨立測試和內建測試。上面這段代碼是獨立測試，我們也嘗試了內建測試的方式，最終代碼如下：
上面一節對之前的homecontroller進行了簡單的測試，現在可以對它進行進一步的完善：将@requestmapping從修飾函數改成修飾類，代碼如下：
在新的homecontroller中，"/"被移動到類級别的@requestmapping中，而定義http方法的@requestmapping仍然用于修飾home()方法。requestmapping注解可以接受字元串數組，即可以同時映射多個路徑，是以我們還可以按照下面這種方式修改：
對于dispatcherservlet傳來的請求，控制器通常不會實作具體的業務邏輯，而是調用業務層的接口，并且将業務層服務傳回的資料放在模型對象中傳回給dispatcherservlet。
在spittr應用中，需要一個頁面顯示最近的spittles清單。首先需要定義資料庫存取接口，這裡不需要提供具體實作，隻需要用mokito架構填充模拟測試資料即可。spittlerepository接口的代碼列舉如下：
spittlerepository接口中的findspittles()方法有兩個參數：max表示要傳回的spittle對象的最大id；count表示指定需要傳回的spittle對象數量。為了傳回20個最近發表的spittle對象，則使用<code>list<spittle> recent = spittlerepository.findspittle(long.max_value, 20)</code>這行代碼即可。該接口要處理的實體對象是spittle，是以還需要定義對應的實體類，代碼如下：
首先為新的控制器接口寫一個測試用例，利用mockito架構模拟repository對象，并模拟出request請求，代碼如下：
單元測試的基本組成是：準備測試資料、調用待測試接口、校驗接口的執行結果。對于shouldshowrecentspittles()這個用例我們也可以這麼分割：首先規定在調用spittlerepository接口的findspittles()方法時将傳回20個spittle對象。
這裡選擇獨立測試，跟homecontrollertest不同的地方在于，這裡建構mockmvc對象時還調用了setsingleview()函數，這是為了防止mock架構從控制器解析view名字。在很多情況下并沒有這個必要，但是對于spittlecontroller控制器來說，視圖名稱和路徑名稱相同，如果使用預設的視圖解析器，則mockmvc會混淆這兩者而失敗，報出如下圖所示的錯誤：
default view resovler will confuse the view name and path
在這裡其實可以随意設定internalresourceview的路徑，但是為了和webconfig中的配置相同。
通過get方法構造get請求，通路"/spittles"，并確定傳回的視圖名稱是"spittles"，傳回的model資料中包含spittlelist屬性，且對應的值為我們之前建立的測試資料。
最後，為了使用hasitems，需要在pom檔案中引入hamcrest庫，代碼如下
現在跑單元測試的話，必然會失敗，因為我們還沒有提供spittlecontroller的對應方法，代碼如下：
model對象本質上是一個map，spittles方法負責填充資料，然後跟視圖的邏輯名稱一起回傳給dispatcherservlet。在調用addattribute方法的時候，如果不指定key字段，則key字段會從value的類型推導出，在這個例子中預設的key字段是spittlelist。
如果你希望顯式指定key字段，則可以按照如下方式指定：
另外，如果你希望盡量少使用spring規定的資料類型，則可以使用map代替model。
還有另一種spittles方法的實作，如下所示：
這個版本和之前的不同，并沒有傳回一個邏輯名稱以及顯式設定model對象，這個方法直接傳回spittle清單。在這種情況下，spring會将傳回值直接放入model對象，并從值類型推導出對應的關鍵字key；然後從路徑推導出視圖邏輯名稱，在這裡是spittles。
無論你選擇那種實作，最終都需要一個頁面——spittles.jsp。jsp頁面使用jstl庫的<c:foreach>标簽擷取model對象中的資料，如下所示：
盡管spittlecontroller還是很簡單，但是它比homecontroller複雜了一點，不過，這兩個控制器都沒有實作的一個功能是處理表單輸入。接下來将擴充spittlecontroller，使其能夠處理表單上輸入。
spring mvc提供了三種方式，可以讓用戶端給控制器的handler傳入參數，包括：
查詢參數（query parameters）
表單參數（form parameters）
路徑參數（path parameters）
spittr應用需要一個頁面顯示spittles清單，目前的spittlecontroller僅能傳回最近的所有spittles，還不能提供根據spittles的生成曆史進行查詢。如果你想提供這個功能，首先要提供使用者一個傳入參數的方法，進而可以決定傳回曆史spittles的那一個子集。
spittles清單是按照id的生成先後倒序排序的：下一頁spittles的第一條spittle的id應正好在目前頁的最後一條spittle的id後面。是以，為了顯示下一頁spttles，應該能夠傳入僅僅小于目前頁最後一條spittleid的參數；并且提供設定每頁傳回幾個spittles的參數count。
before參數，代表某個spittle的id，包含該id的spittles集合中所有的spittles都在目前頁的spittles之前釋出；
count參數，代表希望傳回結果中包含多少條spittles。
我們将改造5.2.3小節實作的spittles()方法，來處理上述兩個參數。首先編寫測試用例：
這個測試用例的關鍵在于：為請求"/spittles"傳入兩個參數，max和count。這個測試用例可以測試提供參數的情況，兩個測試用例都應該提供，這樣可以覆寫到所有測試條件。改造後的spittles方法列舉如下：
如果spittlecontroller的handle方法需要預設處理同時處理兩種情況：提供了max和count參數，或者沒有提供的情況，代碼如下：
其中max_long_as_string是long的最大值的字元串形式，定義為：<code>private static final string max_long_as_string = long.max_value + "";</code>，預設值都給定字元串形式，不過一旦需要綁定到參數上時，就會自動轉為合适的格式。
假設spittr應用應該支援通過指定id顯示對應的spittle，可以使用@requestparam給控制器的處理方法傳入參數id，如下所示：
這個方法将處理類似<code>/spittles/show?spittle_id=12345</code>的請求，盡管這可以工作，但是從基于資源管理的角度并不理想。理想情況下，某個指定的資源應該可以通過路徑指定，而不是通過查詢參數指定，是以get請求最好是這種形式：<code>/spittles/12345</code>。
首先編寫一個測試用例，代碼如下：
該測試用例首先模拟一個repository、控制器和mockmvc對象，跟之前的幾個測試用例相同。不同之處在于這裡構造的get請求——/spittles/12345，并希望傳回的視圖邏輯名稱是spittle，傳回的模型對象中包含關鍵字spittle，且與該key對應的值為我們建立的測試資料。
為了實作路徑參數，spring mvc在@requestmapping注解中提供占位符機制，并在參數清單中通過@pathvariable("spittleid")擷取路徑參數，完整的處理方法列舉如下：
@pathvariable注解的參數應該和@requestmapping注解中的占位符名稱完全相同；如果函數參數也和占位符名稱相同，則可以省略@pathvariable注解的參數，代碼如下所示：
這麼寫确實可以使得代碼更加簡單，不過需要注意：如果要修改函數參數名稱，則要同時修改路徑參數的占位符名稱。
web應用通常不僅僅是給使用者顯示資料，也接受使用者的表單輸入，最典型的例子就是賬号注冊頁面——需要使用者填入相關資訊，應用程式按照這些資訊為使用者建立一個賬戶。
關于表單的處理有兩個方面需要考慮：顯示表單内容和處理使用者送出的表單資料。在spittr應用中，需要提供一個表單供新使用者注冊使用；需要一個spittercontroller控制器顯示注冊資訊。
修飾showregistrationform()方法的@requestmapping(value = "/register", method = requestmethod.get)注解，和類級别的注解一起，表明該方法需要處理類似"/spitter/register"的get請求。這個方法非常簡單，沒有輸入，且僅僅傳回一個邏輯名稱——"registerform"。
即使showregistrationform()方法非常簡單，也應該寫個單元測試，代碼如下所示：
為了接受使用者的輸入，需要提供一個jsp頁面——registerform.jsp，該頁面的代碼如下所示：
上述jsp頁面在浏覽器中渲染圖如下所示：
注冊頁面
因為<form>标簽并沒有設定action參數，是以，當使用者單擊submit按鈕的時候，将向背景發出/spitter/register的post請求。這就需要我們為spittercontroller編寫對應的處理方法。
在處理來自系統資料庫單的post請求時，控制器需要接收表單資料，然後構造spitter對象，并儲存在資料庫中。為了避免重複送出，應該重定向到另一個頁面——使用者資訊頁。
按照慣例，首先編寫測試用例，如下所示：
顯然，這個測試比之前驗證顯示注冊頁面的測試更加豐富。首先設定好spitterrepository對象、控制器和mockmvc對象，然後建構一個post請求——/spitter/register，且該請求會攜帶四個參數，用于模拟submit的送出動作。
在處理post請求的最後一般需要利用重定向到一個新的頁面，以防浏覽器重新整理引來的重複送出。在這個例子中我們重定向到/spitter/jbaure，即新添加的使用者的個人資訊頁面。
最後，該測試用例還需要驗證模拟對象mockrepository确實用于儲存表單送出的資料了，即save()方法之上調用了一次。
在spittercontroller中添加處理表單的方法，代碼如下：
shouldshowregistrationform()這個方法還在，新加的處理方法processregistration()以spitter對象為參數，spring利用post請求所攜帶的參數初始化spitter對象。
現在執行之前的測試用例，發現一個錯誤如下所示：
argument are different
我分析了這個錯誤，原因是測試用例的寫法有問題：<code>verify(mockrepository, atleastonce()).save(unsaved);</code>這行代碼表示，希望調用至少儲存unsave這個對象一次，而實際上在控制器中執行save的時候，參數對象的id是另一個——根據參數新建立的。回顧我們寫這行代碼的初衷：確定save方法至少被調用一次，而儲存哪個對象則無所謂，是以，這行語句改成<code>verify(mockrepository, atleastonce());</code>後，再次執行測試用例就可以通過了。
當internalresourceviewresolver看到這個函數傳回的重定向url是以view标志開頭，就知道需要把該url當做重定向url處理，而不是按照視圖邏輯名稱處理。在這個例子中，頁面将被重定向至使用者的個人資訊頁面。是以，我們還需要給spittercontroller添加一個處理方法，用于顯示個人資訊，showspitterprofile()方法代碼如下：
showspitterprofile()方法根據username從spitterrepository中查詢spitter對象，然後将該對象存放在model對象中，并傳回視圖的邏輯名稱profile。
profile.jsp的頁面代碼如下所示：
上述代碼的渲染圖如下圖所示：
your profile
如果使用者忘記輸入username或者password就點了送出，則可能建立一個這兩個字段為空字元串的spitter對象。往小了說，這是醜陋的開發習慣，往大了說這是會應發安全問題，因為使用者可以通過送出一個空的表單來登入系統。
綜上所述，需要對使用者的輸入進行有效性驗證，一種驗證方法是為processregistration()方法添加校驗輸入參數的代碼，因為這個函數本身非常簡單，參數也不多，是以在開頭加入一些if判斷語句還可以接受。
除了使用這種方法，換可以利用spring提供的java驗證支援（a.k.a jsr-303）。從spring 3.0開始，spring支援在spring mvc項目中使用java validation api。
首先需要在pom檔案中添加依賴：
然後就可以使用各類具體的注解，進行參數驗證了，以spitter類的實作為例：
@notnull注解表示被它修飾的字段不能為空；@size字段用于限制指定字段的長度範圍。在spittr應用的含義是：使用者必須填寫表單中的所有字段，并且滿足一定的長度限制，才可以注冊成功。
除了上述兩個注解，java validation api提供了很多不同功能的注解，都定義在javax.validation.constraints包種，下表列舉出這些注解：
java validation api清單
java validation api清單（續）
在spittr類的定義中規定驗證條件後，需要在控制器的處理方法中應用驗證條件。
如果使用者輸入的參數有誤，則傳回registerform這個邏輯名稱，浏覽器将傳回到表單填寫頁面，以便使用者重新輸入。當然，為了更好的使用者體驗，還需要提示使用者具體哪個字段寫錯了，應該怎麼改；最好是在使用者填寫之前就做出提示，這就需要前端工程師做很多工作了。
這一章比較适合spring mvc的入門學習資料。涵蓋了spring mvc處理web請求的處理過程、如何寫簡單的控制器和控制器方法來處理http請求、如何使用mockito架構測試控制器方法。
基于spring mvc的應用有三種方式讀取資料：查詢參數、路徑參數和表單輸入。本章用兩節介紹了這些内容，并給出了類似錯誤處理和參數驗證等關鍵知識點。
<a href="http://jinnianshilongnian.iteye.com/blog/2004660">— 随着restful web service的流行，測試對外的service是否滿足期望也變的必要的。從spring 3.2開始spring了spring web測試架構，如果版本低于3.2，請使用spring-test-mvc項目（合并到spring3.2中了）。 spring mvc測試架構提供了對伺服器端和用戶端（基于resttemplate的用戶端）提供了支援。 對于伺服器 ...</a>
<a href="http://www.vogella.com/tutorials/mockito/article.html">— testing with mockito this tutorial explains testing with the mockito framework from within the eclipse ide.</a>
<a href="http://www.im47.cn/post/2013/2013-05-21-ni-ying-gai-geng-xin-de-javazhi-shi-zhi-chang-yong-cheng-xu-ku"></a>
<a href="http://examples.javacodegeeks.com/core-java/mockito/mockito-verify-example/">— in this article, i am going to show you an example of mockito verify. to test the state, we use assert, likewise, to verify the test interactions, we use mockito.verify.</a>