MVC模式簡介
一、 MVC 模式概念
MVC 模式的目的是實現一種動態的程序設計，簡化後續對程序的修改和擴展，並且使程序某一部分的重複利用成爲可能。除此之外，MVC 模式通過對複雜度的簡化，使程序的結構更加直觀。軟件系統在分離了自身的基本部分的同時，也賦予了各個基本部分應有的功能。專業人員可以通過自身的專長進行相關的分組：
MVC 模式（Model–view–controller）是軟件工程中的一種軟件架構模式，它把軟件系統分爲三個基本部分：模型（Model）、視圖（View）和控制器（Controller）。
- 模型（Model）：程序員編寫程序應有的功能（實現算法等等）、數據庫專家進行數據管理和數據庫設計(可以實現具體的功能)；
- 控制器（Controller）：負責轉發請求，對請求進行處理；
- 視圖（View）：界面設計人員進行圖形界面設計。
MVC 模式的圖形描述如下：
MVC模式中三個組件的詳細介紹如下：
- 模型（Model）：用於封裝與應用程序的業務邏輯相關的數據以及對數據的處理方法。“Model”有對數據直接訪問的權力，例如對數據庫的訪問。“Model”不依賴“View”和“Controller”，也就是說， Model 不關心它會被如何顯示或是如何被操作。但是 Model 中數據的變化一般會通過一種刷新機制被公佈。爲了實現這種機制，那些用於監視此 Model 的 View 必須事先在此 Model 上註冊，由此，View 可以瞭解在數據 Model 上發生的改變。（比如：觀察者模式（軟件設計模式））；
- 視圖（View）：能夠實現數據有目的的顯示（理論上，這不是必需的）。在 View 中一般沒有程序上的邏輯。爲了實現 View 上的刷新功能，View 需要訪問它監視的數據模型（Model），因此應該事先在被它監視的數據那裏註冊；
- 控制器（Controller）：起到不同層面間的組織作用，用於控制應用程序的流程。它處理事件並作出響應。“事件”包括用戶的行爲和數據 Model 上的改變。
從MVC模式的一般理解來看，視圖層與模型層是存在直接聯繫的，並且模型層的變化會通過視圖層反映出來，這確實是MVC模式的標準理解，不過在我目前接觸到的實際應用中，更多的情況時，視圖層與模型層是通過控制層聯繫起來的，兩者之間並無直接的聯繫，三者之間的關係更類似下圖所示：
總結：
結合MVC模式的標準解釋來看，上述模式可能是MVC模式的一種變型使用，這只是個人的武斷猜測，並無實據，待以後對架構模式有深入瞭解後，就有答案。
二、 優點與缺點
2.1 MVC模式的優點
2.1.1 低耦合
通過將視圖層和業務層分離，允許更改視圖層代碼而不必重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變，只需要改動MVC的模型層（及控制器）即可。因爲模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
模型層是自包含的，並且與控制器和視圖層相分離，所以很容易改變應用程序的數據層和業務規則。如果想把數據庫從 MySQL 移植到 Oracle，或者改變基於 RDBMS 的數據源到 LDAP，只需改變模型層即可。一旦正確的實現了模型層，不管數據來自數據庫或是 LDAP服務器，視圖層都將會正確的顯示它們。由於運用 MVC 的應用程序的三個部件是相互獨立，改變其中一個部件並不會影響其它兩個，所以依據這種設計思想能構造出良好的鬆耦合的構件。
2.1.2 重用性高
隨着技術的不斷進步，當前需要使用越來越多的方式來訪問應用程序了。MVC模式允許使用各種不同樣式的視圖來訪問同一個服務端的代碼，這得益於多個視圖（如WEB（HTTP）瀏覽器或者無線瀏覽器（WAP））能共享一個模型。
比如，用戶可以通過電腦或通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式（流程）是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面（視圖）使用。例如，很多數據可能用 HTML 來表示，但是也有可能用 WAP 來表示，而這些表示的變化所需要的是僅僅是改變視圖層的實現方式，而控制層和模型層無需做任何改變。
由於已經將數據和業務規則從表示層分開，所以可以最大化的進行代碼重用了。另外，模型層也有狀態管理和數據持久性處理的功能，所以，基於會話的購物車和電子商務過程，也能被Flash網站或者無線聯網的應用程序所重用。
2.1.3 生命週期成本低
MVC模式使開發和維護用戶接口的技術含量降低。
2.1.4 部署快
使用MVC模式進行軟件開發，使得軟件開發時間得到相當大的縮減，它使後臺程序員集中精力於業務邏輯，界面程序員集中精力於表現形式上。
2.1.5 可維護性高
分離視圖層和業務邏輯層使得WEB應用更易於維護和修改。
2.1.6 有利軟件工程化管理
由於不同的組件（層）各司其職，每一層不同的應用會具有某些相同的特徵，這樣就有利於通過工程化、工具化的方式管理程序代碼。控制器同時還提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖，來實現用戶的需求，這樣控制器可以爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。
2.2 MVC模式的缺點
2.2.1 沒有明確的定義
完全理解MVC模式並不是很容易。使用MVC模式需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考軟件的架構。同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。
2.2.2 不適合小、中型應用程序
花費大量時間將MVC模式應用到規模並不是很大的應用程序通常會得不償失。
2.2.3 增加系統結構和實現的複雜性
對於簡單的界面來說，非要嚴格遵循MVC模式，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。
2.2.4 視圖對模型數據的低效率訪問
依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
說明：如果通過控制器訪問模型層（而非視圖層直接訪問）