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，看到就是正常的網頁。 全過程結束。