MVC模式（三層架構模式）

（Model-View-Controller）是軟體工程中的一種軟體架構模式，把軟體系統分為三個基本部分：模型（Model）、檢視（View）和控制器（Controller）。

MVC模式最早由Trygve Reenskaug在1974年提出，是施樂帕羅奧多研究中心（Xerox PARC）在20世紀80年代為程式語言Smalltalk發明的一種軟體設計模式。MVC模式的目的是實現一種動態的程式設計，使後續對程式的修改和擴充套件簡化，並且使程式某一部分的重複利用成為可能。除此之外，此模式通過對複雜度的簡化，使程式結構更加直觀。軟體系統通過對自身基本部份分離的同時也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長分組：

• （控制器Controller）- 負責轉發請求，對請求進行處理。
• （檢視View） - 介面設計人員進行圖形介面設計。
• （模型Model） - 程式設計師編寫程式應有的功能（實現演算法等等）、資料庫專家進行資料管理和資料庫設計(可以實現具體的功能)。

MVC工作原理

MVC是一個設計模式，它強制性的使應用程式的輸入、處理和輸出分開。使用MVC應用程式被分成三個核心部件：模型、檢視、控制器。它們各自處理自己的任務。

檢視

　　檢視是使用者看到並與之互動的介面。對老式的Web應用程式來說，檢視就是由HTML元素組成的介面，在新式的Web應用程式中，HTML依舊在檢視中扮演著重要的角色，但一些新的技術已層出不窮，它們包括Macromedia Flash和像XHTML，XML/XSL，WML等一些標識語言和Web services. 　　如何處理應用程式的介面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程式處理很多不同的檢視。在檢視中其實沒有真正的處理髮生，不管這些資料是聯機儲存的還是一個僱員列表，作為檢視來講，它只是作為一種輸出資料並允許使用者操縱的方式。

模型

　　模型表示企業資料和業務規則。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用像EJBs和ColdFusion Components這樣的構件物件來處理資料庫。被模型返回的資料是中立的，就是說模型與資料格式無關，這樣一個模型能為多個檢視提供資料。由於應用於模型的程式碼只需寫一次就可以被多個檢視重用，所以減少了程式碼的重複性。

控制器

　　控制器接受使用者的輸入並呼叫模型和檢視去完成使用者的需求。所以當單擊Web頁面中的超連結和傳送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定呼叫哪個模型構件去處理請求，然後確定用哪個檢視來顯示模型處理返回的資料。 　　現在我們總結MVC的處理過程，首先控制器接收使用者的請求，並決定應該呼叫哪個模型來進行處理，然後模型用業務邏輯來處理使用者的請求並返回資料，最後控制器用相應的檢視格式化模型返回的資料，並通過表示層呈現給使用者。

MVC框架模式的優點

     1、開發人員可以只關注整個結構中的其中某一層；     2、可以很容易的用新的實現來替換原有層次的實現；     3、可以降低層與層之間的依賴；     4、有利於標準化；     5、利於各層邏輯的複用。

MVC框架模式的缺點

　　（1） 增加了系統結構和實現的複雜性。對於簡單的介面，嚴格遵循MVC，使模型、檢視與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低執行效率。 　　（2） 檢視與控制器間的過於緊密的連線。檢視與控制器是相互分離，但確實聯絡緊密的部件，檢視沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。　　（3）檢視對模型資料的低效率訪問。依據模型操作介面的不同，檢視可能需要多次呼叫才能獲得足夠的顯示資料。對未變化資料的不必要的頻繁訪問，也將損害操作效能。

瞭解真正所謂的"框架"

我們到底要什麼

　　在回顧了我們寫程式碼的歷史之後，我們回過頭來看看，我們到底要什麼？

　　無論是使用JSP，還是使用Struts1，或是Struts2，我們至少都需要一些必須的元素（如果沒有這些元素，或許我還真不知道這個程式會寫成什麼樣子）：

　　1. 資料

　　在這個例子中，就是name和password。他們共同構成了程式的核心載體。事實上，我們往往會有一個User類來封裝name和password，這樣會使得我們的程式更加OO。無論怎麼說，資料會穿插在這個程式的各處，成為程式執行的核心。

　　2. 頁面展示

　　在這個例子中，就是login.jsp。沒有這個頁面，一切的請求、驗證和錯誤展示也無從談起。在頁面上，我們需要利用HTML，把我們需要展現的資料都呈現出來。同時我們也需要完成一定的頁面邏輯，例如，錯誤展示，分支判斷等等。

　　3. 處理具體業務的場所

　　在這裡，不同階段，處理具體業務的場所就不太一樣。原來用JSP和Servlet，後來用Struts1或者Struts2的Action。

　　上面的這些必須出現的元素，在不同的年代，被賦予了不同的表現形式，有的受到時代的束縛，其表現形式非常落後，有的已經不再使用。但是撥開這些外在的表現形式，我們就可以發現，這不就是我們已經熟門熟路的MVC嘛？

　　資料 ———— Model

　　頁面展示 ———— View

處理具體業務的場所 ———— Control

　　所以，框架不重要，概念是王道。只要能夠深刻理解MVC的概念，框架對你來說，只是一個jar包而已。

　　MVC的概念其實就那麼簡單，這些概念其實早已深入我們的內心，而我們所缺乏的是將其本質挖掘出

來。我們來看看下面這幅圖，這是一副流行了很多年的講述MVC模型的圖：

　　在這幅圖中，MVC三個框框各司其職，結構清晰明朗。不過我覺得這幅圖忽略了一個問題，就是資料是動的，資料在View和Control層一旦動起來，就會產生許多的問題：

　　1. 資料從View層傳遞到Control層，如何使得一個個扁平的字串，轉化成一個個生龍活虎的Java物件

　　2. 資料從View層傳遞到Control層，如何方便的進行資料格式和內容的校驗？

　　3. 資料從Control層傳遞到View層，一個個生龍活虎的Java物件，又如何在頁面上以各種各樣的形式展現出來

　　4. 如果你試圖將資料請求從View層傳送到Control層，你如何才能知道你要呼叫的究竟是哪個類，哪個方法？一個Http的請求，又如何與Control層的Java程式碼建立起關係來？

　　除此之外，Control層似乎也沒有想象中的那麼簡單，因為它作為一個控制器，至少還需要處理以下的問題：

　　1. 作為呼叫邏輯處理程式的facade門面，如果邏輯處理程式發生了異常，我們該如何處理？

　　2. 對於邏輯處理的結果，我們需要做怎麼樣的處理才能滿足豐富的前臺展示需要？

　　這一個又一個問題的提出，都基於對MVC的基本概念的挖掘。所以，這些問題都需要我們在寫程式的時候去一一解決。說到這裡，這篇文章開頭所提的問題應該可以有答案了：框架是為了解決一個又一個在Web開發中所遇到的問題而誕生的。不同的框架，都是為了解決不同的問題，但是對於程式設計師而言，他們只是jar包而已。框架的優缺點的評論，也完全取決於其對問題解決程度和解決方式的優雅性的評論。所以，千萬不要為了學習框架而學習框架，而是要為了解決問題而學習框架，這才是一個程式設計師的正確學習之道。