MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範。
那麼MVC框架究竟幹了些什麼：用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件裏面。各部分相互獨立並且相互聯繫。可以讓各自專注於自己的任務。但是不得不承認MVC只能稱之爲低耦合性。
優點在於：用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件裏面，在改進和個性化定製界面及用戶交互的同時，不需要重新編寫業務邏輯。也就是說邏輯層面全部位於C（controller）層，另外兩層專注於視圖層和模型（數據層）的書寫。那麼很顯而易見Controller層在MVC框架中起到了很重要的作用（承上啓下）。
以下貼上最經典的MVC框架圖
期中Model層幹得最多的就是數據庫訪問，拿到數據並返回給Controller
那麼這麼做的優缺點呢：以下是從某百科上down下來的，自己理解纔是王道
優點
耦合性低
視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因爲模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。
模型是自包含的，並且與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。如果把數據庫從MySQL移植到Oracle，或者改變基於RDBMS數據源到LDAP，只需改變模型即可。一旦正確的實現了模型，不管數據來自數據庫或是LDAP服務器，視圖將會正確的顯示它們。由於運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想能構造良好的鬆耦合的構件。
重用性高
隨着技術的不斷進步，需要用越來越多的方式來訪問應用程序。MVC模式允許使用各種不同樣式的視圖來訪問同一個服務器端的代碼，因爲多個視圖能共享一個模型，它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數據可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。由於已經將數據和業務規則從表示層分開，所以可以最大化的重用代碼了。模型也有狀態管理和數據持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。
生命週期成本低
MVC使開發和維護用戶接口的技術含量降低。
部署快
使用MVC模式使開發時間得到相當大的縮減，它使程序員（Java開發人員）集中精力於業務邏輯，界面程序員（HTML和JSP開發人員）集中精力於表現形式上。
可維護性高
分離視圖層和業務邏輯層也使得WEB應用更易於維護和修改。
有利軟件工程化管理
由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化管理程序代碼。控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以爲構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給用戶。[12-13]
缺點
沒有明確的定義
完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。同時由於模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。
不適合小型，中等規模的應用程序
花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失。
增加系統結構和實現的複雜性
對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。
視圖與控制器間的過於緊密的連接
視圖與控制器是相互分離，但卻是聯繫緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
視圖對模型數據的低效率訪問
依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
一般高級的界面工具或構造器不支持模式
改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，會造成MVC使用的困難。
同時，MVC框架基本上使用於所有的面嚮對象語言，同時在MVC中體現中了很濃重的MVC思想 。畢竟如今是一個面向對象的年代。
這裏我自己畫了一張自定義MVC框架的簡易示意圖（很多語言是有自己的MVC框架的，但都大同小異）
上圖
看圖請參照下面這段解釋：
我們從最底層網上層解釋
- sqlhelper（數據庫操作工具）類是專門進行一些對數據庫操作的封裝，將對數據庫的操作進行整合，一般爲單例模式（不允許通過new來實例化）並且只能有一個其對象。
- 基礎模型類 實際上乾的事情只有一個就是所有的模型類本應該都乾的事情：拿到sqlHelper的實例化的類 。所以他只幹一件事情，僞實例化一個數據庫操作類。好處在於代碼的整合
- 模型類 所有模型類都繼承於基礎模型類 可以調用基礎模型類實例化的類 。另外對一類對象的操作都應該放在一個模型類裏面
- controller類 控制器 主要是邏輯調用 包含各種Action（動作）方法 主要作用拿到想要的數據 傳給model層 拿到結果集並處理
- 前端控制器（請求分發器） 接收從前端發來的url 分析 C爲Controller A爲 Action 並實例化對應的controller類，調用對應的Action 方法。入口文件
具體流程：
視圖層請求前端控制器 ， 前端控制器根據其url確定實例化某個Controller控制器 ， 並調用對應的Action方法 Action方法調用對應的model（數據層），model繼承於基礎模型類 通過sqlhelper實例化的類對數據庫操作，拿到結果集。返回給Controller控制器，Controller要麼給視圖層返回數據 ，要麼調用視圖層填充數據。
整個架構雖然看起來繁瑣，但其既體現出面向對象的思想，又將程序代碼重複部分進行的整合，架構清晰，明瞭，並且後期修改複用性較強。
文章不懂，寫的有問題的地方請及時留言指出。
轉載請註明出處