爲什麼要使用SpringMVC
爲什麼要使用springMVC?他的出現解決了什麼問題？
首先回顧一下WebMVC:
如果沒有MVC設計模式。程序間的各層之間依賴非常強，耦合度高。嚴重違背了高內聚低耦合的設計原則。而WebMVC將控制邏輯和功能處理，模型和視圖進行了分離。降低耦合但是WebMVC也有嚴重的缺點：
- 控制器(controller）
1.控制邏輯較爲複雜，而且每個模塊都需要一個控制器，（可能每一個頁面都需要一個控制器）
2.請求參數到模型的封裝麻煩。
3.視圖的選擇嚴重依賴於Servlet API ，這樣很能甚至不可能更換視圖
4.給視圖傳入模型數據 也依賴於Servlet API.如果要更換視圖那麼技術也要改變。 - 模型(model)
使用JavaBean組件，（域模型層+業務層+持久層）導致JavaBean組件類龐大。不利於開發人員管理 - 視圖(view)
被綁定於Jsp,很難更換視圖
如何解決WebMVC的缺點
從服務到工作者模式：
服務到工作者：Front Controller + Application Controller + Page Controller + Context即，前端控制器+應用控制器+頁面控制器（也有稱其爲動作）+上下文
前端控制器:
負責爲表現層提供統一訪問點，從而避免WebMVC中出現的重複的控制邏輯,可以爲多個請求提供共用的邏輯（如準備上下文等等）,
將選擇具體視圖和具體的功能處理分離。
應用控制器:
前端控制器分離選擇具體視圖和具體的功能處理之後，需要有人來管理，應用控制器就是用來選擇具體視圖技術（視圖的管理）和具體的功能處理（頁面控制器/命令對象/動作管理），一種策略設計模式的應用，可以很容易的切換視圖/頁面控制器，相互不產生影響
頁面控制器/動作/處理器：
功能處理代碼，收集參數、封裝參數到模型，轉調業務對象處理模型，返回邏輯視圖名交給前端控制器（和具體的視圖技術解耦），由前端控制器委託給應用控制器選擇具體的視圖來展示，可以是命令設計模式的實現。頁面控制器也被稱爲處理器或動作。
上下文
WebMVC中爲視圖準備要展示的模型數據，我們直接放在request中（Servlet API相關），有了上下文之後，我們就可以將相關數據放置在上下文，從而與協議無關（如Servlet API）的訪問/設置模型數據，一般通過ThreadLocal模式實現。
web設計遵循的原則
乾淨的web表現層：
模型和視圖的分離；
控制器中的控制邏輯與功能處理分離（收集並封裝參數到模型對象、業務對象調用）；
控制器中的視圖選擇與具體視圖技術分離。
輕薄的web表現層：
做的事情越少越好，薄薄的，不應該包含無關代碼；
只負責收集並組織參數到模型對象，啓動業務對象的調用；
控制器只返回邏輯視圖名並由相應的應用控制器來選擇具體使用的視圖策略；
儘量少使用框架特定API，保證容易測試。
而SpringMVC就是按照從服務到工作者的模式設計的。
