MVC的主要宗旨是把所有的對(duì)象分為三個(gè)陣營(yíng)，model陣營(yíng)、view陣營(yíng)和controller陣營(yíng)
----那這些陣營(yíng)是干什么的？
一、model陣營(yíng)是你的應(yīng)用是做什么的（ Model = What your application is (but not how it is displayed)）
舉個(gè)例子：你在做一個(gè)人的模型，這個(gè)人的身高，體重，性別 就是 model，這些都是“這個(gè)程序是什么”的一部分，這就是model。我并沒(méi)有說(shuō)關(guān)于這個(gè)人的相貌、衣著，這些和model沒(méi)有關(guān)系，那是view和controller干的事。
二、controller：你可以認(rèn)為是你的model如何展現(xiàn)在用戶面前（Controller = How your Model is presented to the user (UI logic)）
它獲取了這個(gè)人的身高等并將這些計(jì)算出怎么在屏幕上展現(xiàn)出來(lái)。這就是controller，controller 控制如何在UI上展現(xiàn)model。
三、view 是 controller 的仆人，view 就是controller使用的工具（View = Your Controller’s minions）
我們盡可能的使view陣營(yíng)里的對(duì)象通用化，就像按鈕、滑動(dòng)條，這些都是蘋(píng)果自帶的。
view絕對(duì)不包含任何有關(guān)于如何去表現(xiàn)應(yīng)用。
controller 利用這些通用view來(lái)做model需要做的事情。
view應(yīng)該是很通用的，這很重要。因?yàn)橄到y(tǒng)上有很多view，還有和應(yīng)用相關(guān)的功能來(lái)控制view，所以我們要更先進(jìn)一點(diǎn)，利用通用的view來(lái)理解和使用這些功能。
四、一旦你有了三個(gè)陣營(yíng)，剩下的就是他們之間的管理和通信問(wèn)題
接下來(lái)我要談一下哪些通信是被允許的，還有如何去完成
-
讓我們聊一下controller是怎樣向model發(fā)消息的：
controller向model發(fā)消息是100%被允許的（Controllers can always talk directly to their Model） controller可以問(wèn)model任何問(wèn)題，controller知道m(xù)odel的任何事情 因?yàn)閏ontroller就是用來(lái)把model展現(xiàn)在屏幕上的，所以他要有完全的訪問(wèn)權(quán) 這個(gè)箭頭是單向的，所以只有controller知道m(xù)odel 這里畫(huà)的像一個(gè)交通標(biāo)志，從controller到model是白色虛線，所以可以隨時(shí)跨過(guò)去
-
那么controller和view通信會(huì)是怎么樣呢？
controller是要把model顯示在屏幕上，所以他可以對(duì)view做任何事（Controllers can also talk directly to their View） 例如設(shè)個(gè)標(biāo)志，讓view做些東西，在屏幕上排列view，數(shù)據(jù)通信 看見(jiàn)單詞outlet，outlet是一個(gè)表達(dá)式，用來(lái)表示controller的用來(lái)和view通信的一個(gè)屬性 所以我們要在controller里創(chuàng)建outlets傳到view中去
-
那么model和view是怎樣的呢？
它們永遠(yuǎn)不會(huì)相互通信（The Model and View should never speak to each other） 我相信你們都理解為什么model不和view通信，因?yàn)閙odel和用戶交互界面無(wú)關(guān) model是完全UI獨(dú)立的
有些人會(huì)說(shuō)，我有一些自定義view，掌控著model，所以能夠顯示model。這聽(tīng)起來(lái)挺吸引人的，但這不是個(gè)好主意的原因—重用。因?yàn)槟惆裿iew和model連在了一起，model變了以后view要重寫(xiě)，view不能被重復(fù)利用，model也不能被其他UI用。比如iPad出來(lái)了，因?yàn)槠聊淮笮≡蛐枰粋€(gè)新的UI，你就得要重寫(xiě)整個(gè)view。
最好是把這部分放到controller里，建一些更通用的view對(duì)象。另一個(gè)原因是，如果view和model通信，那么現(xiàn)在所有人能和model通信了，view在和model通信，controller在和model通信，model就有點(diǎn)hold不住了。如果只有controller在和model通信就能容易很多搞清楚程序在干什么，把view排除在外，view只是controller的仆人，讓controller來(lái)通信。
- view能否允許和controller通信？
答案是某種程度上是可以的，view（通用的）和 controller（詳細(xì)控制如何在屏幕展現(xiàn)model）之間的通信是不可見(jiàn)的，view不知道自己在和誰(shuí)說(shuō)話。但有一個(gè)好的架構(gòu)，所以Xcode里我們有組織的連接view和它的controller。
所以，view向controller通信的方法，有結(jié)構(gòu)的方法，一個(gè)被稱為target action。target action很簡(jiǎn)單，就是controller自己畫(huà)了一個(gè)target，然后把一個(gè)action交給他的view，當(dāng)view發(fā)生了一些事情，比如按鈕被按滑動(dòng)條移動(dòng)，它會(huì)把a(bǔ)ction發(fā)到target，然后controller就知道按鈕被按了。這就是view向controller通信的機(jī)制，view回報(bào)controller發(fā)生了什么。但是view對(duì)controller知道的并不多，只是簡(jiǎn)單的發(fā)送target action。
事實(shí)上，還有view和controller之間比較復(fù)雜的通信，比如，view要和controller保持同步，所以常常view要告訴controller發(fā)生了什么，這是圖上的did；或者將要發(fā)生什么，這是will；或者要問(wèn)controller我是否允許什么發(fā)生，這是should。所以這些will、did、should是view要問(wèn)的問(wèn)題，這么做的原因是controller把自己設(shè)為委托（The Controller sets itself as the View’s delegate）。
用協(xié)議，設(shè)立一個(gè)協(xié)議，來(lái)回應(yīng)will，did，should。
再一次，view不用知道回應(yīng)的controller是哪一個(gè)類，delegation是另一個(gè)view和controller通信的方法。
另一個(gè)重要的事是，view不是它顯示的數(shù)據(jù)的所有者 （ View do not own the data they display），你們要了解view不擁有數(shù)據(jù)，view只是一個(gè)平面，用來(lái)顯示數(shù)據(jù)，一個(gè)顯示信息的平臺(tái)。view沒(méi)有實(shí)體變量也不會(huì)去存儲(chǔ)，只有指向他們的指針。比如你iPod庫(kù)里的1000首歌不會(huì)是view的實(shí)體變 量，這種設(shè)計(jì)使得，比如view不會(huì)去管理數(shù)據(jù)庫(kù)，更新iPod歌曲庫(kù)。這不是view的活，而是controller或者model干的。
但如果view不擁有它所顯示的數(shù)據(jù)，它如何獲取數(shù)據(jù)呢？
一個(gè)類似delegation的方法，他有一些協(xié)議，比如這里的data at 和 count 方法。這對(duì)一個(gè)表挺有用的，表可以去問(wèn)表里有多少東西 ，比如5000，那好我要在第100到第150條數(shù)據(jù)，我要用來(lái)顯示。view根據(jù)需求去請(qǐng)求數(shù)據(jù)，這會(huì)非常高效的，如果另外一頭知道怎么管理一個(gè)巨大的數(shù)據(jù)庫(kù)，而只提取其中需要的幾條，因?yàn)槟鉯Pod里有1000首歌，但屏幕上一次只顯示7條。你要這種功能，但不要把他寫(xiě)在一個(gè)view里，view是通用的用來(lái)顯示的，controller和model一起來(lái)有效率的提供信息。
類似的，view會(huì)有一個(gè)數(shù)據(jù)源的設(shè)置，controller會(huì)回應(yīng)數(shù)據(jù)源（Controllers are almost always that data source (not Model ! )），注意，數(shù)據(jù)源的delegation永遠(yuǎn)是controller，或者是controller指定的第三方，但不可能是model，controller的工作是把model的信息傳達(dá)給view，相應(yīng)所有的delegation。因?yàn)樗塬@取model里的數(shù)據(jù)，決定怎么在屏幕上顯示，這是他的職能，所以他要參與這個(gè)循環(huán)。
你們可能需要這些data at 和 count 方法，可能只是一行代碼，問(wèn)model數(shù)據(jù)是什么，然后model把數(shù)據(jù)給你。即使只是一行代碼，也需要controller來(lái)參與，因?yàn)檫@是controller的工作，獲取model顯示在屏幕上。
上文重復(fù)了5遍“這是controller的工作”，因?yàn)檫@在iOS中很重要，你要給它機(jī)會(huì)做他的工作。
永遠(yuǎn)不要超過(guò)view和model之間的線。
五、還有一件事，model能向controller發(fā)話嗎？
這個(gè)很明顯，肯定不行的。model是UI獨(dú)立的，不能向controller發(fā)話，這是controller的工作來(lái)用view顯示model。那么當(dāng)model的一些東西改變了，你需要更新controller的時(shí)候該怎么辦呢？假設(shè)你有個(gè)數(shù)據(jù)庫(kù)，某人在數(shù)據(jù)庫(kù)里寫(xiě)了某些東西，然后比如那個(gè)人的模型的屬性被外界的事物改變了，現(xiàn)在model改變了是因?yàn)槿俗兣至恕?br>
在iOS里我們實(shí)現(xiàn)的東西是用一個(gè)廣播站就像信息廣播機(jī)制，有2個(gè)機(jī)制，通知和關(guān)鍵數(shù)據(jù)監(jiān)聽(tīng)。當(dāng)model改變了，他就在廣播站廣播，然后controller接收到了，去model里把什么東西改了。這個(gè)過(guò)程是無(wú)形的，也是同時(shí)的。
這就是Notification & KVO。這里的kvo也可以用于view和controller，但不會(huì)是view和model，view不會(huì)有面向model的廣播，view和controller會(huì)相互有廣播。
model廣播非常好用，因?yàn)槭遣豢梢?jiàn)的，所以存在限制，只能通過(guò)被允許通信的對(duì)象發(fā)生了什么事。
六、MVC群
現(xiàn)在我們有了各個(gè)陣營(yíng)所有的通信機(jī)制，我們要建一個(gè)復(fù)雜應(yīng)用。復(fù)雜應(yīng)用不僅僅只有一個(gè)controller、view，它會(huì)擁有幾十個(gè)controller和view。比如登陸界面，點(diǎn)擊了什么出來(lái)了一個(gè)表，再點(diǎn)一下表出來(lái)個(gè)其他什么的。各種各樣的view被controller管理著，那要怎么做復(fù)雜應(yīng)用呢？
答案是把MVC組成MVC群。
七、controller能否可以和其他人的view對(duì)話？
通常controller只會(huì)有個(gè)指針只想另外一個(gè)controller來(lái)當(dāng)做view，它會(huì)根據(jù)那個(gè)controller來(lái)顯示東西。controller的工作就是獲取信息，顯示信息。當(dāng)controller需要顯示復(fù)雜的東西時(shí)，他需要其他的controller。
一個(gè)view只有一個(gè)與其搭配的controller。