1.跟蹤mvc請求

請求會由DispatcherServlet分配給控制器(Controller)根據Handler mapping來確定，在Controller完成處理后，接著請求會被發送給一個視圖（View）由ViewResolver來確定

2.搭建mvc

     <servlet>        <servlet-name>mvc-demo</servlet-name>        <servlet-class>            org.sPRingframework.web.servlet.DispatcherServlet        </servlet-class>        <load-on-startup>1</load-on-startup>    </servlet>

servlet-name 很重要 默認情況下DispatcherServlet在加載時會從一個基于servlet-name的xml文件mvc-demo-servlet.xml位于WEB-INF目錄下

接下來我們必須聲明DispatcherServlet處理哪些URL比較常見的DispatcherServlet匹配模式是*.htm,/*或者/app 但這些模式都存在一些問題

將其匹配到/*上的話，沒有映射制定類型的響應，它表明DispatcherServlet將處理所有的請求。這會在處理圖片或者樣式表這樣的靜態資源時帶來不必要的麻煩

/app模式 幫助我們區分了dispatcherServlet處理的內容和其他內容，但這樣就會在URL中暴露實現的細節（具體來說是/app路徑）為了隱藏/app路徑通常需要復雜的URL重寫技巧

為了不使用有缺陷的servlet匹配模式，更傾向使用

<servlet-mapping>    <servlet-name>mvc-demo</servlet-name>    <url-pattern>/</url-pattern></servlet-mapping>

通過映射到/ 聲明會處理所有的請求，包括對靜態資源的請求。

Spring提供了一個方便的配置，使得我們不必過于擔心細節Spring的Mvc明明空間包含了一個新的<mvc:resources>元素，他會處理靜態資源的請求。

<mvc:resources mapping="/resources/**" location="/resources/"></mvc:resources>

3.配置注解驅動的Spring mvc 

DispatcherServlet需要咨詢一個或多個處理器映射來明確地將請求分發給哪個控制器。Spring自帶了多個處理器映射實現供我們選擇。

BeanNameUrlHandlerMapping:根據控制器bean的名字將控制器映射到URL

ControllerBeanNameHandlerMapping：與BeanNameUrlHandlerMapping類似，根據控制器Bean的名字將控制器映射到URL。使用該處理器映射實現，

Bean的名字不需要遵循URL的約定。

ControllerClassNameHandlerMapping 通過使用控制器的類名作為URL基礎將控制器映射到URL

DefaultAnnotationHandlerMapping 將請求映射給使用@RequestMapping注解控制器

SimpleUrlHandlerMapping 使用定義在Spring應用上下文的屬性集合將控制器映射到URL

4.定義控制器

@Controller注解表明這是一個控制器類，這個類是@Component是注解的一種具體化，也就是說<context:component-scan>將查找使用@Component注解那樣

這意味著需要在配置文件中配置一個<context:component-scan>這樣Controller類將會自動被發現并注冊為Bean.

@RequestMapping注解指明方法要處理的路徑請求

5.解析視圖

為了確定指定的請求需要使用哪個視圖，DispatcherServlet會查找一個視圖解析器來將控制器返回的邏輯視圖名稱轉換成渲染結果的實際視圖

實際上，視圖解析器的工作是將邏輯視圖的名字與org.springframework.web.servlet.View的實現相匹配。

6.完成Spring應用上下文

DispatcherServlet會根據一個xml文件來加載其Spring應用上下文，而這個文件的名字基于它的servlet-name來確定

contextLoaderListener是一個Servlet監聽器，除了DispatcherServlet創建的應用上下文以外，它能夠加載其他配置文件。

為了使用ContextLoadListener需要在web.xml文件中添加如下的Listener聲明

<listener>  <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class></listener>

必須告訴ContextLoaderListener需要加載那些配置文件。如果沒有指定，上下文加載器會查找/WEB-INF/applicationContext.xml

這個配置文件。但這個文件本身并沒有做到將應用上下文拆分為多個片段，所以我們要重寫默認實現。

為了給ContextLoaderListener指定一個或多個Spring配置文件，需要在servlet上下文配置contextConfigLocation參數

<context-param>  <param-name>contextConfigLocation</param-name>  <param-value>  classpath:service-context.xml    </param-value></context-param>

7.@RequestMapping 

類級別的@RequestMapping定義了這個控制器所處理的根URL路徑。最終會在Controller中添加多個處理方法，每個方法處理不同的請求，但請求必須都以

類級別@RequestMapping配置的路徑名開頭

方法級別的@RequestMapping縮小了類級別所定義的@RequestMapping路徑匹配。method屬性表明Http的請求類型

params參數能夠限制處理方法只對包含特定參數的請求進行處理。

@RequestParam注解表明它的值應該根據請求的參數來獲取。

在方法中可以傳遞Map<String,Object>或者Model參數。Model提供了幾個更便利的方法來填充模型

如：addAttribute()與map的put方法所做的事情完全一樣，只不過它能夠自己計算出map的鍵部分，key為類名

@Valid注解 這表明Spitter在傳入之前需要通過校驗。

8.重定向

前綴redirect:說明請求將被重定向到指定路徑。對于重定向的路徑，將采用/xxx/{yyy}這樣的形式

9.處理帶有路徑變量的請求

@ReqeustMapping(value="/{yyy}",method=RequestMethod.GET)

10.校驗輸入

@Valid注解是防御錯誤表單輸入的第一道防線，@Valid是JSR-303的一部分。

如果校驗出錯的話，檢驗錯誤將會作為第二個參數以BindingResult的形式傳遞給方法，

如果BindingResult的hasErrors方法返回true就意味著校驗失敗了。

展現校驗錯誤

為用戶展現這些錯誤的一種方式就是通過BindingResult的getFieldError()方法來獲取字段的錯誤

但更好的一種方式是使用Spring的表單綁定jsp標簽庫

<sf:errors>

11.文件上傳