MVC(Model View Controller)模型(model)－視圖(view)－控制器(controller)：
MVC本來是存在于Desktop程序中的，M是指數據模型，V是指用戶界面，C則是控制器。使用MVC是將M和V的實現代碼分離，從而使同一個程序可以使用不同的表現形式。比如一批統計數據你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新，從例子可以看出MVC就是Observer設計模式的一個特例。

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

 （一）模型對象
模型對象封裝了應用程序的數據，并定義操控和處理該數據的邏輯和運算。例如，模型對象可能是表示游戲中的角色或地址簿中的聯系人。用戶在視圖層中所進行的創建或修改數據的操作，通過控制器對象傳達出去，最終會創建或更新模型對象。模型對象更改時（例如通過網絡連接接收到新數據），它通知控制器對象，控制器對象更新相應的視圖對象。在MVC的三個部件中，模型擁有最多的處理任務。例如它可能用象EJBs和ColdFusion Components這樣的構件對象來處理數據庫。被模型返回的數據是中立的，就是說模型與數據格式無關，這樣一個模型能為多個視圖提供數據。由于應用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復性。

（二）視圖對象
視圖對象是應用程序中用戶可以看見的對象。視圖對象知道如何將自己繪制出來，并可能對用戶的操作作出響應。視圖對象的主要目的，就是顯示來自應用程序模型對象的數據，并使該數據可被編輯。盡管如此，在 MVC 應用程序中，視圖對象通常與模型對象分離。在iOS應用程序開發中，所有的控件、窗口等都繼承自 UIView，對應MVC中的V。UIView及其子類主要負責UI的實現，而UIView所產生的事件都可以采用委托的方式，交給UIViewController實現。

（三）控制器對象
在應用程序的一個或多個視圖對象和一個或多個模型對象之間，控制器對象充當媒介。控制器對象因此是同步管道程序，通過它，視圖對象了解模型對象的更改，反之亦然。控制器對象還可以為應用程序執行設置和協調任務，并管理其他對象的生命周期。

控制器對象解釋在視圖對象中進行的用戶操作，并將新的或更改過的數據傳達給模型對象。模型對象更改時，一個控制器對象會將新的模型數據傳達給視圖對象，以便視圖對象可以顯示它。

為什么要使用 MVC
　  首先，最重要的一點是多個視圖能共享一個模型，現在需要用越來越多的方式來訪問你的應用程序。對此，其中一個解決之道是使用MVC，無論你的用戶想要Flash界面或是 WAP 界面；用一個模型就能處理它們。由于你已經將數據和業務規則從表示層分開，所以你可以最大化的重用你的代碼了。
　　由于模型返回的數據沒有進行格式化，所以同樣的構件能被不同界面使用。例如，很多數據可能用HTML來表示，但是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和數據持久性處理的功能，例如，基于會話的購物車和電子商務過程也能被Flash網站或者無線聯網的應用程序所重用。
　　因為模型是自包含的，并且與控制器和視圖相分離，所以很容易改變你的應用程序的數據層和業務規則。如果你想把你的數據庫從MySQL移植到Oracle，或者改變你的基于RDBMS數據源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的數據來自數據庫或是LDAP服務器，視圖將會正確的顯示它們。由于運用MVC的應用程序的三個部件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。
　　對我來說，控制器也提供了一個好處，就是可以使用控制器來聯接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構造應用程序提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據用戶的需求選擇模型進行處理，然后選擇視圖將處理結果顯示給用戶。
MVC的優點
（一）、低耦合性
　　視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則。

（二）、高重用性和可適用性
　　隨著技術的不斷進步，現在需要用越來越多的方式來訪問應用程序。MVC模式允許你使用各種不同樣式的視圖來訪問同一個服務器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，用戶可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由于模型返回的數據沒有進行格式化，所以同樣的構件能被不同的界面使用。例如，很多數據可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。

（三）、較低的生命周期成本
　　MVC使開發和維護用戶接口的技術含量降低。

（四）、可維護性
　　分離視圖層和業務邏輯層也使得應用更易于維護和修改。

（五）、有利于軟件工程化管理
　　由于不同的層各司其職，每一層不同的應用具有某些相同的特征，有利于通過工程化、工具化管理程序代碼。

MVC的缺點：
　　MVC的缺點是由于它沒有明確的定義，所以完全理解MVC并不是很容易。使用MVC需要精心的計劃，由于它的內部原理比較復雜，所以需要花費一些時間去思考。
　　你將不得不花費相當可觀的時間去考慮如何將MVC運用到你的應用程序，同時由于模型和視圖要嚴格的分離，這樣也給調試應用程序帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。一旦你的構件經過了測試，你就可以毫無顧忌的重用它們了。
　　根據開發者經驗，由于開發者將一個應用程序分成了三個部件，所以使用MVC同時也意味著你將要管理比以前更多的文件，這一點是顯而易見的。這樣好像我們的工作量增加了，但是請記住這比起它所能帶給我們的好處是不值一提。
　　MVC并不適合小型甚至中等規模的應用程序，花費大量時間將MVC應用到規模并不是很大的應用程序通常會得不償失。
　　MVC設計模式是一個很好創建軟件的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構件，你可能需要重新思考你的應用程序，尤其是應用程序的構架方面。如果你肯接受MVC，并且有能力應付它所帶來的額外的工作和復雜性，MVC將會使你的軟件在健壯性，代碼重用和結構方面上一個新的臺階。

IOS MVC設計模式：

圖中有幾條線把這三部分劃分開，有黃線，虛線，和白色的實線。我們把它們想象成路標。你可以看到，在M和V之間有兩條黃線，這表示什么呢？它意味著你不能 穿越這黃線，任何一個方向都不行，即M和V完全分離。在圖的上部，你可以看到白色的虛線，它意味著你可以自由的穿越它，只要是安全的。那白色的實線呢？它代表你可以穿越，但你必須要買票，或者交點過路費。

首先， 我們來看C和M之間的綠色箭頭，這箭頭的方向就代表著“發起對話”的方向，也就是說，發起對話的是C，而做出回答的是M。C可以問M各種各樣的問題，但M 只是回答C的問題或要求，它不可以主動的向C要求什么。還記得虛線是暢通無阻的意思吧，所以，C知道M的所有的事情,如果用代碼來說明這件事情，就是 說，C可以導入M的頭文件或是M的接口（API）。因為C可以通過M的API，所以它就可以肆無忌憚的向M要求這要求那了。

我們再來看看另外的一個綠色箭頭，它是在C和V之間，和前一個綠色箭頭的意義一樣，它代表C可以直接地向V進行交流。你可以想想，C要把V放到屏幕 上，并設置V的屬性，告訴它們什么時候從屏幕上消失，把它們分成組等等。如果C不能自由的向V發號施令的話，程序的顯示將會多么的困難,所以，C可以毫無 限制地向V說話。

可能你已經注意到了，這個箭頭上還有outlet(輸出口)，outlet可以看作是從C指向V的指針，它在C中被定義。outlet給我們提供了很大的 方便，它使我們在C的內部就可以輕松準確地向V施令。C可以擁有很多的outlet，可以不止一個，這也使它可以更高效的和V進行交流。

那M和V之間可以交流么？還記得黃線的意思么？完全不可以通過，所以我們是不允許M和V進行交流的。這是因為我們不希望這三部分之間有過多的交流，你想想，假如V在顯示時出現了問題，比如有一個圖形沒有顯示出來，我們就要去查找錯誤，因為C可以和V交流，M也可以和V交流的話，我們就要去檢查兩個部分。 相反的，只有C可以和V交流的話，在出錯時，我們就只需要去C那里查找原因，這樣查找錯誤不就很是簡單了么？所以，我們不允許M和V之間有直接的聯系，這 也是在它們兩之間有兩根黃線的原因。 總結下來也就是以下三點：

（1）、Model和View永遠不能相互通信，只能通過Controller傳遞。

（2）、Controller可以直接與Model對話（讀寫調用Model），Model通過Notification和KVO機制與Controller間接通信。

（3）、Controller可以直接與View對話，通過outlet,直接操作View,outlet直接對應到View中的控件,View通過action向Controller報告事件的發生(如用戶Touch我了)。Controller是View的直接數據源（數據很可能是Controller從Model中取得并經過加工了）。Controller是View的代理（delegate),以同步View與Controller。

我們接下來討論V是如何向C發送信息的。V對C的交流有三種不同的方式：

第一種我們稱為目標操作(target-action)。

它是這樣工作的，C會在自己的內部“懸掛”一個目標(target)，如圖中的紅白相間的 靶子，對應的，它還會分發一個操作(action，如圖中的黃色箭頭)給將要和它交流的視圖對象(可能是屏幕上的一個按鈕)，當按鈕被按時，action 就會被發送給與之對應的target，這樣V就可以和C交流了。但是在這種情況下，V只是知道發送action給對應的target,它并不知道C中的 類，也不知道它到底發送了什么。target-action是我們經常使用的方法。

 第二種方式我們叫做委托(delegate)。

有時候，V需要和C進行同步，你知道，用戶交互不僅僅是什么按按鈕，劃滑塊，還有很多種形式。好了， 讓我們來看看圖中的delegate黃色箭頭，你發現箭頭上又分出了四個小箭頭：should，did，will，還有一個沒標注的。絕大部分的 delegate信息都是should，will，did這三種形式。和英文意思相對應，should代表視圖對象將詢問C中的某個對象“我應該這么做 么？”，舉個例子，有一個web視圖，有人點擊了一個鏈接，web視圖就要問“我應該打開這個鏈接么？這樣做安全么？”。這就是should信息。那 will和did呢？will就是“我將要做這件事了”，did就是“我已經做了這件事”。C把自己設置為V的委托(delegate),它讓V知道：如 果V想知道更多的關于將如何顯示的信息的話，就向C發送delegate信息。通過接受V發過來的delegate信息，C就會做出相應的協調和處理。還 有一點，每個V只能有一個delegate。

第三種方式就是數據源(datasource)，

V不能擁有它所要顯示的數據，記住這點非常重要。V希望別人幫助它管理將要顯示的數據，當 它需要數據時，它就會請求別人的幫助,把需要的數據給它。再者，iphone的屏幕很小，它不能顯示包含大量信息的視圖。看圖中的datasource箭 頭，和delegate類似，V會發送cout，data at信息給C來請求數據。

對于不同的UIView，有相應的UIViewController，對應MVC中的C。例如在iOS上常用的UITableView，它所對應的Controller就是UITableViewController。