MVC的全名是Model View Controller，是模型(Model)－視圖(view)－控制器(controller)的縮寫，是一種設計模式。它是用一種業務邏輯、數據與界面顯示分離的方法來組織代碼，將眾多的業務邏輯聚集到一個部件里面，在需要改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯，達到減少編碼的時間，提高代碼復用性。
使用的MVC的目的：它將這些對象、顯示、控制分離以提高軟件的的靈活性和復用性，MVC結構可以使程序具有對象化的特征，也更容易維護。
Model、View、Controller概述：
模型層（Model）：指從現實世界中抽象出來的對象模型，是應用邏輯的反應；它封裝了數據和對數據的操作，是實際進行數據處理的地方（模型層與數據庫才有交互）
視圖層（View）：是應用和用戶之間的接口，它負責將應用顯示給用戶 和 顯示模型的狀態。
控制器（Controller）:控制器負責視圖和模型之間的交互，控制對用戶輸入的響應、響應方式和流程；它主要負責兩方面的動作，一是把用戶的請求分發到相應的模型，二是吧模型的改變及時地反映到視圖上。
在網頁當中，
V即View視圖是指用戶看到並與之交互的界面。比如由html元素組成的網頁界面，或者軟件的客戶端界面。MVC的好處之一在於它能為應用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發生，它只是作為一種輸出數據並允許用戶操縱的方式。
M即model模型是指模型表示業務規則。在MVC的三個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，模型與數據格式無關，這樣一個模型能為多個視圖提供數據，由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。
C即controller控制器是指控制器接受用戶的輸入並調用模型和視圖去完成用戶的需求，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然后再確定用哪個視圖來顯示返回的數據。
用戶首先在界面中進行人機交互，然后請求發送到控制器，控制器根據請求類型和請求的指令發送到相應的模型，模型可以與數據庫進行交互，進行增刪改查操作，完成之后，根據業務的邏輯選擇相應的視圖進行顯示，此時用戶獲得此次交互的反饋信息，用戶可以進行下一步交互，如此循環。
需要注意的是：MVC三層結構與軟件的三層結構是有區別的。MVC是一種設計模式，三層結構是軟件結構，用MVC這種設計模式可以實現三層軟件結構。在完整三層軟件結構中 表現層包括了MVC中的表現層和控制層。而MVC中的模型層其實包括了三層軟件結構的業務邏輯層、數據訪問層、業務實體類（model）和共用類。軟件三層結構的UI（Web）包含了MVC中的視圖層（V）和控制層（C）。
MVC舉例一：
最典型的MVC就是jsp+servlet+javabean模式。
JavaBean作為模型，既可以作為數據模型來封裝業務數據，又可以作為業務邏輯模型來包含應用的業務操作。其中，數據模型用來存儲或傳遞業務數據，而業務邏輯模型接收到控制器傳過來的模型更新請求后，執行特定的業務邏輯處理，然后返回相應的執行結果。
JSP作為視圖層，負責提供頁面為用戶展示數據，提供相應的表單（Form）來用於用戶的請求，並在適當的時候（點擊按鈕）向控制器發出請求來請求模型進行更新。
Serlvet作為控制器，用來接收用戶提交的請求，然后獲取請求中的數據，將之轉換為業務模型需要的數據模型，然后調用業務模型相應的業務方法進行更新，同時根據業務執行結果來選擇要返回的視圖。
MVC設計模式相對於模式1（虛線表示模式1，不是MVC，即JSP+JavaBean），把模式1 的表現層中的頁面與表現邏輯（流程控制）分開。視圖層只負責頁面的顯示，而數據的獲取、調用業務邏輯和頁面的選擇均由控制層完成。在MVC模式中，視圖層用JSP、HTML、CSS和JavaScript技術來實現；
MVC舉例二：
Struts2框架：Struts2是基於MVC的輕量級的web應用框架。Struts2的應用范圍是Web應用，注重將Web應用領域的日常工作和常見問題抽象化，提供一個平台幫助快速的完成Web應用開發。基於Struts2開發的Web應用自然就能實現MVC，Struts2着力於在MVC的各個部分為開發提供相應幫助。
下面通過代碼來簡單解釋一下：
Login.html
Login.java
Struts.xml
用戶首先在Login.html中輸入用戶名和密碼，點擊登陸，此時根據action的路徑，在struts.xml中找到對應的Login，然后根據對應的class的路徑進入相應的login.Java，在這里判斷之后，返回success或error，然后根據struts.xml中的result值，指向相應的jsp頁面。
控制器——filterdispatcher
從上面這張圖來看，用戶請求首先到達前端控制器FilterDispatcher。FilterDispatcher負責根據用戶提交的URL和struts.xml中的配置，來選擇合適的動作(Action)，讓這個Action來處理用戶的請求。FilterDispatcher其實是一個過濾器（Filter，servlet規范中的一種web組件），它是Struts2核心包里已經做好的類，不需要我們去開發，只是要在項目的web.xml中配置一下即可。FilterDispatcher體現了J2EE核心設計模式中的前端控制器模式。
動作——Action
在用戶請求經過FilterDispatcher之后，被分發到了合適的動作Action對象。Action負責把用戶請求中的參數組裝成合適的數據模型，並調用相應的業務邏輯進行真正的功能處理，獲取下一個視圖展示所需要的數據。Struts2的Action，相比於別的web框架的動作處理，它實現了與Servlet API的解耦，使得Action里面不需要再直接去引用和使用HttpServletRequest與HttpServletResponse等接口。因而使得Action的單元測試更加簡單，而且強大的類型轉換也使得我們少做了很多重復的工作。
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
2.重用性高
MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因為多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。
3.部署快，生命周期成本低
MVC使開發和維護用戶接口的技術含量降低。使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。
4.可維護性高
分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。
MVC的缺點：
1.完全理解MVC比較復雜。
由於MVC模式提出的時間不長，加上同學們的實踐經驗不足，所以完全理解並掌握MVC不是一個很容易的過程。
2.調試困難。
因為模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難，每個構件在使用之前都需要經過徹底的測試。
3.不適合小型，中等規模的應用程序
在一個中小型的應用程序中，強制性的使用MVC進行開發，往往會花費大量時間，並且不能體現MVC的優勢，同時會使開發變得繁瑣。
4.增加系統結構和實現的復雜性
對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率。
5.視圖與控制器間的過於緊密的連接並且降低了視圖對模型數據的訪問
視圖與控制器是相互分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。