SpringMVC是什么？

一，首先是一個MVC框架。

在web模型中，MVC是一種很流行的框架，通過把Model，View，Controller分離，把較為復雜的web應用分成邏輯清晰的幾部分，是為了簡化開發，減少出錯。還是為了組內開發人員之間的配合。總之就是一種分層工作的辦法。

二，springMVC，是spring的一個子框架，當然擁有spring的特性，如依賴注入。

三，springMVC的信息流是什么樣的？

首先用戶通過HTTP請求到服務器，服務器會根據你的url來將請求轉到不同的控制器Controller。這是第一步，具體需要做的是在web.xml中設置URLpattern映射到spring的DispatcherServlet，這是控制器是負責第一道處理，用來轉發請求的，它會將請求轉發到合適的Controller上。那么問題來了，它是根據什么轉發呢？這個問題有些混亂，原因是springMVC一直在升級，不斷貢獻新的url到Controller的映射方法。但是萬變不離其宗，不管如何變，它的目的都不變，就是設法建立url到Controller的映射，找到這個目的之后，看起來就容易一些。具體來看，

方法1，在springmvc的配置文件中，直接將bean的name寫成一個url，如

<bean name=”/product_input” class="com.ap.ProductInputController" />

通過這句配置，就直接將/product_input這url的請求轉發到了ProductInputController這個類上。

注：但是這個方法被認為是老套的方法，現在已經不流行了。了解就可以，現在推薦的是注解的方式，即方法2的方式。

方法2，這種方式，在給Controller命名時，就可以無所謂了， 它的映射不是依賴這個名字，所以可以像下面這種方式來寫這個bean的配置，可以隨便起一個，如

<bean name=”product” class="com".ap.ProductInputController />

到這里，顯然還是沒有實現url到Controller的映射，因為url都還沒看見呢，

現在的springMVC有一個注解是RequestMapping，專門負責映射url的，比方說需要映射到ProductInputController的 addProduct()這個方法，只需要在這個方法上加上一個注解，如

@RequestMapping(name=”product_input”)

addProduct()

通過這個注解，就可以將product_input這個url映射到addProduct這個方法了。是不是很簡單。其實做的事情都一樣，只不過是換了一種寫法和位置。

感覺好神奇的樣子，我一開始也有這種感覺，直到我了解了原始Servlet是如何將url和處理業務的類聯系起來的，才發現這個過程也沒有那么神秘，這里推薦一本書《SpringMVC學習指南》 Paul Deck著，適合0基礎的人看，例子很詳細。

我大概說一下url到Controller是怎么回事：

起點是，用戶通過HTTP請求了服務器，那么一定就有URL，比方說是http://www.dudu.com/getName，其中getName就是我的url，假設你的servlet是部署在tomcat中的，在web.xml這個配置文件中，應該有url到某個類的關系，或者通過別的注解的方法 如@Webservlet(name= “xxController”, urlPatterns = {“product_input”}), 這里意思就是這個url進來后，把請求交給xxController這個class去處理，這個類繼承了HttpServlet, 并且重寫的doGet方法，你的請求就會來到這個方法里，然后，在方法內調用request.getRequestURI這個方法，拿到了你的url=getName，之后就是字符串匹配equals，調用后面具體的類。

我們使用框架的原因，就是在開發中，這樣的步驟都是重復的，而且每次都一樣，所以寫框架的人，就把這樣套路式的代碼封裝了， 細節都交給他來處理，我們只要做兩件和自己業務相關的事，一個是確定url，二是，這個url指向那個類。寫到這里基本把url到Controller這件事說完了。這里有兩個類一個是DispatcherServlet，這個是SpringMVC框架自帶的，一個就是你自己處理業務的類，比如是ProductController。控制器的命名都喜歡叫XXXController。下面畫一張圖說明這一步

四，MVC，先說的居然是C，Controller，下面說View，就是視圖，展示。用戶的瀏覽器，看到的都是比較美觀的網頁，這就是HTML，它負責來將苦澀的數據，展現成各種樣式，讓普通用戶看起來也不錯，而不是一堆JSON數據。用戶的請求進來之后，肯定還是要返回給用戶頁面的，這每個頁面就是一個VIEW，view就像一個網頁的框架，某個頁面的框架是固定的，不同的是其中的數據。比方說購物車頁面，就是一個框架。那你的購物車和我的大體看起來是一樣的，但其中的具體內容不同，因為買的商品不同，而這具體的東西，或叫做數據，就是Model。現在M和V就有了。

下面再串一個這個流程，剛才說到請求已經到了Controller，這個類的作用就是1，選擇適當的view返回給用戶，2，組織數據，即生成Model。網絡傳輸和信息技術主要處理的就是數據，而現在數據就放在Model中，或者把放數據的地方叫做Model，比如用戶在請求查詢用戶信息，那么Controller做的就是，在數據庫中找到這些信息，然后把信息添加到Model中，然后把Model和對應的View一起返回給DispatcherServlet。 這里繼續補充上一張圖：

五，現在DispatcherServlet已經拿到Model里的數據和該用哪個View來展示給用戶了。

所以會將Model和View融合，具體就是用Model的數據把View的變量都換成具體的值，然后view就變成一個HTML的頁面了，最后把這個HTML返回給用戶，用戶那邊用瀏覽器來解釋HTML，看到就是正常的網頁。 全過程結束。