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

MVC是一個(gè)設(shè)計(jì)模式，它強(qiáng)制性的使應(yīng)用程序的輸入、處理和輸出分開(kāi)。使用MVC應(yīng)用程序被分成三個(gè)核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)。分層概念

 （一）模型對(duì)象
模型對(duì)象封裝了應(yīng)用程序的數(shù)據(jù)，并定義操控和處理該數(shù)據(jù)的邏輯和運(yùn)算。例如，模型對(duì)象可能是表示游戲中的角色或地址簿中的聯(lián)系人。用戶在視圖層中所進(jìn)行的創(chuàng)建或修改數(shù)據(jù)的操作，通過(guò)控制器對(duì)象傳達(dá)出去，最終會(huì)創(chuàng)建或更新模型對(duì)象。模型對(duì)象更改時(shí)（例如通過(guò)網(wǎng)絡(luò)連接接收到新數(shù)據(jù)），它通知控制器對(duì)象，控制器對(duì)象更新相應(yīng)的視圖對(duì)象。在MVC的三個(gè)部件中，模型擁有最多的處理任務(wù)。例如它可能用象EJBs和ColdFusion Components這樣的構(gòu)件對(duì)象來(lái)處理數(shù)據(jù)庫(kù)。被模型返回的數(shù)據(jù)是中立的，就是說(shuō)模型與數(shù)據(jù)格式無(wú)關(guān)，這樣一個(gè)模型能為多個(gè)視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫一次就可以被多個(gè)視圖重用，所以減少了代碼的重復(fù)性。

（二）視圖對(duì)象
視圖對(duì)象是應(yīng)用程序中用戶可以看見(jiàn)的對(duì)象。視圖對(duì)象知道如何將自己繪制出來(lái)，并可能對(duì)用戶的操作作出響應(yīng)。視圖對(duì)象的主要目的，就是顯示來(lái)自應(yīng)用程序模型對(duì)象的數(shù)據(jù)，并使該數(shù)據(jù)可被編輯。盡管如此，在 MVC 應(yīng)用程序中，視圖對(duì)象通常與模型對(duì)象分離。在iOS應(yīng)用程序開(kāi)發(fā)中，所有的控件、窗口等都繼承自 UIView，對(duì)應(yīng)MVC中的V。UIView及其子類主要負(fù)責(zé)UI的實(shí)現(xiàn)，而UIView所產(chǎn)生的事件都可以采用委托的方式，交給UIViewController實(shí)現(xiàn)。

（三）控制器對(duì)象
在應(yīng)用程序的一個(gè)或多個(gè)視圖對(duì)象和一個(gè)或多個(gè)模型對(duì)象之間，控制器對(duì)象充當(dāng)媒介。控制器對(duì)象因此是同步管道程序，通過(guò)它，視圖對(duì)象了解模型對(duì)象的更改，反之亦然。控制器對(duì)象還可以為應(yīng)用程序執(zhí)行設(shè)置和協(xié)調(diào)任務(wù)，并管理其他對(duì)象的生命周期。

控制器對(duì)象解釋在視圖對(duì)象中進(jìn)行的用戶操作，并將新的或更改過(guò)的數(shù)據(jù)傳達(dá)給模型對(duì)象。模型對(duì)象更改時(shí)，一個(gè)控制器對(duì)象會(huì)將新的模型數(shù)據(jù)傳達(dá)給視圖對(duì)象，以便視圖對(duì)象可以顯示它。

為什么要使用 MVC
　  首先，最重要的一點(diǎn)是多個(gè)視圖能共享一個(gè)模型，現(xiàn)在需要用越來(lái)越多的方式來(lái)訪問(wèn)你的應(yīng)用程序。對(duì)此，其中一個(gè)解決之道是使用MVC，無(wú)論你的用戶想要Flash界面或是 WAP 界面；用一個(gè)模型就能處理它們。由于你已經(jīng)將數(shù)據(jù)和業(yè)務(wù)規(guī)則從表示層分開(kāi)，所以你可以最大化的重用你的代碼了。
　　由于模型返回的數(shù)據(jù)沒(méi)有進(jìn)行格式化，所以同樣的構(gòu)件能被不同界面使用。例如，很多數(shù)據(jù)可能用HTML來(lái)表示，但是它們也有可能要用Adobe Flash和WAP來(lái)表示。模型也有狀態(tài)管理和數(shù)據(jù)持久性處理的功能，例如，基于會(huì)話的購(gòu)物車和電子商務(wù)過(guò)程也能被Flash網(wǎng)站或者無(wú)線聯(lián)網(wǎng)的應(yīng)用程序所重用。
　　因?yàn)槟Ｐ褪亲园模⑶遗c控制器和視圖相分離，所以很容易改變你的應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。如果你想把你的數(shù)據(jù)庫(kù)從MySQL移植到Oracle，或者改變你的基于RDBMS數(shù)據(jù)源到LDAP，只需改變你的模型即可。一旦你正確的實(shí)現(xiàn)了模型，不管你的數(shù)據(jù)來(lái)自數(shù)據(jù)庫(kù)或是LDAP服務(wù)器，視圖將會(huì)正確的顯示它們。由于運(yùn)用MVC的應(yīng)用程序的三個(gè)部件是相互獨(dú)立，改變其中一個(gè)不會(huì)影響其它兩個(gè)，所以依據(jù)這種設(shè)計(jì)思想你能構(gòu)造良好的松耦合的構(gòu)件。
　　對(duì)我來(lái)說(shuō)，控制器也提供了一個(gè)好處，就是可以使用控制器來(lái)聯(lián)接不同的模型和視圖去完成用戶的需求，這樣控制器可以為構(gòu)造應(yīng)用程序提供強(qiáng)有力的手段。給定一些可重用的模型和視圖，控制器可以根據(jù)用戶的需求選擇模型進(jìn)行處理，然后選擇視圖將處理結(jié)果顯示給用戶。
MVC的優(yōu)點(diǎn)
（一）、低耦合性
　　視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個(gè)應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需要改動(dòng)MVC的模型層即可。因?yàn)槟Ｐ团c控制器和視圖相分離，所以很容易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。

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

（三）、較低的生命周期成本
　　MVC使開(kāi)發(fā)和維護(hù)用戶接口的技術(shù)含量降低。

（四）、可維護(hù)性
　　分離視圖層和業(yè)務(wù)邏輯層也使得應(yīng)用更易于維護(hù)和修改。

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

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

IOS MVC設(shè)計(jì)模式：

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

首先， 我們來(lái)看C和M之間的綠色箭頭，這箭頭的方向就代表著“發(fā)起對(duì)話”的方向，也就是說(shuō)，發(fā)起對(duì)話的是C，而做出回答的是M。C可以問(wèn)M各種各樣的問(wèn)題，但M 只是回答C的問(wèn)題或要求，它不可以主動(dòng)的向C要求什么。還記得虛線是暢通無(wú)阻的意思吧，所以，C知道M的所有的事情,如果用代碼來(lái)說(shuō)明這件事情，就是 說(shuō)，C可以導(dǎo)入M的頭文件或是M的接口（API）。因?yàn)镃可以通過(guò)M的API，所以它就可以肆無(wú)忌憚的向M要求這要求那了。

我們?cè)賮?lái)看看另外的一個(gè)綠色箭頭，它是在C和V之間，和前一個(gè)綠色箭頭的意義一樣，它代表C可以直接地向V進(jìn)行交流。你可以想想，C要把V放到屏幕 上，并設(shè)置V的屬性，告訴它們什么時(shí)候從屏幕上消失，把它們分成組等等。如果C不能自由的向V發(fā)號(hào)施令的話，程序的顯示將會(huì)多么的困難,所以，C可以毫無(wú) 限制地向V說(shuō)話。

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

那M和V之間可以交流么？還記得黃線的意思么？完全不可以通過(guò)，所以我們是不允許M和V進(jìn)行交流的。這是因?yàn)槲覀儾幌Ｍ@三部分之間有過(guò)多的交流，你想想，假如V在顯示時(shí)出現(xiàn)了問(wèn)題，比如有一個(gè)圖形沒(méi)有顯示出來(lái)，我們就要去查找錯(cuò)誤，因?yàn)镃可以和V交流，M也可以和V交流的話，我們就要去檢查兩個(gè)部分。 相反的，只有C可以和V交流的話，在出錯(cuò)時(shí)，我們就只需要去C那里查找原因，這樣查找錯(cuò)誤不就很是簡(jiǎn)單了么？所以，我們不允許M和V之間有直接的聯(lián)系，這 也是在它們兩之間有兩根黃線的原因。 總結(jié)下來(lái)也就是以下三點(diǎn)：

（1）、Model和View永遠(yuǎn)不能相互通信，只能通過(guò)Controller傳遞。

（2）、Controller可以直接與Model對(duì)話（讀寫調(diào)用Model），Model通過(guò)Notification和KVO機(jī)制與Controller間接通信。

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

我們接下來(lái)討論V是如何向C發(fā)送信息的。V對(duì)C的交流有三種不同的方式：

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

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

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

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

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

V不能擁有它所要顯示的數(shù)據(jù)，記住這點(diǎn)非常重要。V希望別人幫助它管理將要顯示的數(shù)據(jù)，當(dāng) 它需要數(shù)據(jù)時(shí)，它就會(huì)請(qǐng)求別人的幫助,把需要的數(shù)據(jù)給它。再者，iphone的屏幕很小，它不能顯示包含大量信息的視圖。看圖中的datasource箭 頭，和delegate類似，V會(huì)發(fā)送cout，data at信息給C來(lái)請(qǐng)求數(shù)據(jù)。

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