前言：MVC模式用於應用程序的分層開發，MVC要實現的目標是將數據、業務邏輯和軟件用戶界面分離以提高代碼的可擴展性和可維護性。。
一、MVC模式的簡介
1、MVC模式的概念
MVC模式的全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，是一種軟件設計典範。它是用一種業務邏輯、數據與界面顯示分離的方法來組織代碼，將衆多的業務邏輯聚集到一個部件裏面，在需要改進和個性化定製界面及用戶交互的同時，不需要重新編寫業務邏輯，達到減少編碼的時間。
View層是界面，Model層是業務邏輯和數據，Controller層用來調度View層和Model層，將數據、業務邏輯和用戶界面合理的組織在一起，起粘合劑的效果。所以Controller中的內容能少則少，這樣才能提供最大的靈活性。
2、MVC模式的歷史發展
a、在桌面程序中
MVC開始是存在於桌面程序中的，M是指業務模型，V是指用戶界面，C則是控制器。
使用的MVC的目的：在於將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如Windows系統資源管理器文件夾內容的顯示方式，下面兩張圖中左邊爲詳細信息顯示方式，右邊爲中等圖標顯示方式，文件的內容並沒有改變，改變的是顯示的方式。不管用戶使用何種類型的顯示方式，文件的內容並沒有改變，達到M和V分離的目的。
b、在網頁當中
V即View視圖是指用戶看到並與之交互的界面。比如由html元素組成的網頁界面，或者軟件的客戶端界面。MVC的好處之一在於它能爲應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理髮生，它只是作爲一種輸出數據並允許用戶操縱的方式。
M即model模型是指模型表示業務規則和數據。在MVC的三個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，模型與數據格式無關，這樣一個模型能爲多個視圖提供數據，由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重複性。
C即controller控制器是指控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後再確定用哪個視圖來顯示返回的數據。
MVC舉例：
最典型的MVC就是jsp+servlet+javabean模式。
JavaBean作爲模型(Model)，既可以作爲數據模型來封裝業務數據，又可以作爲業務邏輯模型來包含應用的業務操作。其中，數據模型用來存儲或傳遞業務數據，而業務邏輯模型接收到控制器傳過來的模型更新請求後，執行特定的業務邏輯處理，然後返回相應的執行結果。
JSP作爲表現層(View)，負責提供頁面爲用戶展示數據，提供相應的表單（Form）來用於用戶的請求，並在適當的時候（點擊按鈕）向控制器發出請求來請求模型進行更新。
Serlvet作爲控制器(Controller)，用來接收用戶提交的請求，然後獲取請求中的數據，將之轉換爲業務模型需要的數據模型，然後調用業務模型相應的業務方法進行更新，同時根據業務執行結果來選擇要返回的視圖。
二、MVC模式總結
1、MVC要實現的目標是將數據、業務邏輯和軟件用戶界面分離以以使代碼可擴展性、可複用性、可維護性、靈活性加強。
View層是界面，Model層是業務邏輯和數據，Controller層用來調度View層和Model層，將數據、業務邏輯和用戶界面合理的組織在一起，起粘合劑的效果。所以Controller中的內容能少則少，這樣才能提供最大的靈活性。
比方說，有一個View會提交數據給Model進行處理以實現具體的行爲，View通常不會直接提交數據給Model，它會先把數據提交給Controller，然後Controller再將數據轉發給Model。假如此時程序業務邏輯的處理方式有變化，那麼只需要在Controller中將原來的Model換成新實現的Model就可以了，控制器的作用就是這麼簡單， 用來將不同的View和不同的Model組織在一起，順便替雙方傳遞消息，僅此而已。
2、合理的使用MVC有很多好處，要一一道盡是一件異常困難的任務。在這裏我們通過一個反面示例來側面的證明正確使用MVC的好處與依據。很多程序員偏愛於將業務邏輯放在Controller中，我極力反對這種做法，現在我就來證明這中做法的錯誤性。
我們知道在寫程序時，業務邏輯的重複使用是經常要面對的場景。 如果業務邏輯寫在控制器中， 要重用它的唯一方法就是將它提升到父類之中，通過繼承來達到代碼複用的效果。但這麼做會帶來一個巨大的副作用，違背了一項重要的面向對象設計原則：接口隔離。
什麼是接口隔離，我在這裏簡單的講述一下。通俗一點講，接口隔離就是當一個類需要繼承另一個類時， 如果被繼承的類中有繼承的類用不到的方法或者屬性時，就不要去實現這個繼承。如果真的情非得已必須要繼承，那麼也需要從被繼承的類中再提取出一個只包含需要部分功能的新類型，最終去繼承這個新類型纔是正確的做法。 換句話說，實現繼承的時候，不要去繼承那些用不到的事物。
回到之前的話題，通過繼承父控制器的方式複用業務邏輯時，往往會出現爲了重用一個方法而繼承來一大堆用不到的方法，表面上看起來似乎沒什麼問題，但是這會使代碼變的難以理解，長此以往， 軟件的代碼會朝着不健康的方向發展。
要知道，使用繼承的條件是很苛刻的，我們學習面向對象變編程繼承特性時，第一課就是隻有滿足IS-A（是一個）關係時纔可以使用繼承，如果僅僅是複用代碼，並不是我們使用繼承的理由。使用組合是複用代碼提倡的方式，也就是所謂的HAS-A（有一個）的關係，相信每個程序員都聽過“少用繼承，多有組合”這句話，這句話是軟件開發業的先驅們千錘百煉總結出來的，值得我們去遵循。
各Model之間是可以相互調用的， Controller也可以無障礙的調用Model，因此將業務邏輯放在Model中可以靈活的使用組合的方式複用代碼。
而Controller之間是不可以相互調用的，要複用代碼只能將代碼提升至父類，通過繼承實現，顯然這種做法既不正確，也不靈活，因此完全不提倡。
綜上所述，僅僅只是代碼複用這一點，也足以將“厚Controller，薄Model”這種不健康的MVC思想打入十八層地獄。
三、MVC框架的優點
1、耦合性低
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因爲模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
2、代碼重用性高
MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因爲多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。
3、部署快，生命週期成本低
MVC使開發和維護用戶接口的技術含量降低。使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上
4、有利軟件工程化管理
由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化管理程序代碼。控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶
四、Spring MVC 的架構
爲解決持久層中一直未處理好的數據庫事務的編程，又爲了迎合 NoSQL 的強勢崛起，Spring MVC 給出了方案：
傳統的模型層被拆分爲了業務層(Service)和數據訪問層（DAO,Data Access Object）。 在 Service 下可以通過 Spring 的聲明式事務操作數據訪問層，而在業務層上還允許我們訪問 NoSQL ，這樣就能夠滿足異軍突起的 NoSQL 的使用了，它可以大大提高互聯網系統的性能。
特點：
結構鬆散，幾乎可以在 Spring MVC 中使用各類視圖
松耦合，各個模塊分離
與 Spring 無縫集成
參考鏈接：深入理解MVC模式