本文描述設(shè)計(jì)模式在Cocoa框架中的主要實(shí)現(xiàn)方式，特別是模型-視圖-控制器和對(duì)象建模模式，主要目的是使您對(duì)Cocoa的設(shè)計(jì)模式有更好的認(rèn)識(shí)，鼓勵(lì)您在自己的軟件工程中利用這些模式。

模型-視圖-控制器模式（MVC）是一個(gè)相當(dāng)老的設(shè)計(jì)模式，它的一些變體至少在Smarttalk的早期就出現(xiàn)了。它是一種高級(jí)別的模式，關(guān)注的是應(yīng)用程序的全局架構(gòu)，并根據(jù)各種對(duì)象在程序中發(fā)揮的作用對(duì)其進(jìn)行分類。它也是個(gè)復(fù)合的模式，因?yàn)樗怯蓭讉€(gè)更加基本的模式組成的。

面向?qū)ο蟮某绦蛟谠O(shè)計(jì)上采用MVC模式會(huì)帶來(lái)幾個(gè)方面的好處。這種程序中的很多對(duì)象可能更具重用性，它們的接口也可能定義得更加良好。程序從總體上更加適應(yīng)需求的改變—換句話說(shuō)，它們比不基于MVC的程序更加容易擴(kuò)展。而且，Cocoa中的很多技術(shù)和架構(gòu)—比如綁定技術(shù)、文檔架構(gòu)、和腳本技術(shù)—都基于MVC，而且要求您的定制對(duì)象充當(dāng)MVC定義的某種角色。

MVC對(duì)象的作用和關(guān)系

MVC設(shè)計(jì)模式考慮三種對(duì)象：模型對(duì)象、視圖對(duì)象、和控制器對(duì)象。模式定義了這三種對(duì)象在應(yīng)用程序中充當(dāng)?shù)慕巧约八鼈兊耐ㄓ嵚窂健Ｔ谠O(shè)計(jì)應(yīng)用程序時(shí)，一個(gè)主要的步驟就是進(jìn)行這三種對(duì)象的選擇－或者說(shuō)為這三種對(duì)象創(chuàng)建定制類。三種對(duì)象中的每一種都和其它兩種按抽象的邊界區(qū)分，并和其它兩種對(duì)象進(jìn)行跨邊界的通訊。

模型對(duì)象負(fù)責(zé)包裝數(shù)據(jù)和基本行為

模型對(duì)象代表特別的知識(shí)和專業(yè)技能，它們負(fù)責(zé)保有應(yīng)用程序的數(shù)據(jù)和定義操作數(shù)據(jù)的邏輯。一個(gè)定義良好的MVC應(yīng)用程序會(huì)將所有重要的數(shù)據(jù)封裝在模型對(duì)象中。任何代表應(yīng)用程序留存狀態(tài)的數(shù)據(jù)（無(wú)論該狀態(tài)存儲(chǔ)在文件中，還是存儲(chǔ)在數(shù)據(jù)庫(kù)中），一旦載入應(yīng)用程序，就應(yīng)該駐留在模型對(duì)象中。因?yàn)樗鼈兇砼c特定問(wèn)題域有關(guān)的知識(shí)和專業(yè)技能，所以有可能被重用。

在理想情況下，模型對(duì)象不和負(fù)責(zé)表示與編輯模型數(shù)據(jù)的用戶界面建立顯式的連接。舉例來(lái)說(shuō)，如果有個(gè)代表一個(gè)人的模型對(duì)象（假定您在編寫(xiě)一個(gè)地址本），您可能希望存儲(chǔ)這個(gè)人的生日，則將生日存儲(chǔ)在您的Person模型對(duì)象是比較好的做法。但是，日期格式字符串或其它有關(guān)日期如何表示的信息可能存儲(chǔ)在別的地方比較好。

在實(shí)踐上，這種分隔并不總是***的，這里有一定的靈活空間。但一般來(lái)說(shuō)，模型對(duì)象不應(yīng)該關(guān)心界面和表示的問(wèn)題。一個(gè)具有合理例外的例子是描畫(huà)程序，它的模型對(duì)象代表要顯示的圖形。圖形對(duì)象知道如何描畫(huà)自身是合理的，因?yàn)樗鼈兇嬖诘闹饕蚓褪菫榱硕x視覺(jué)上的信息。但是即使在這種情況下，圖形對(duì)象也不應(yīng)該完全依賴于特定的視圖，它們不應(yīng)該負(fù)責(zé)描畫(huà)的具體位置，而應(yīng)該由希望表示這些圖形對(duì)象的視圖對(duì)象發(fā)出描畫(huà)的請(qǐng)求。

進(jìn)一步閱讀：模型對(duì)象實(shí)現(xiàn)指南文檔種討論模型對(duì)象的正確設(shè)計(jì)和實(shí)現(xiàn)。

視圖對(duì)象負(fù)責(zé)向用戶表示信息

視圖對(duì)象知道如何顯示應(yīng)用程序的模型數(shù)據(jù)，而且可能允許用戶對(duì)其進(jìn)行編輯。視圖對(duì)象不應(yīng)該負(fù)責(zé)存儲(chǔ)它所顯示的數(shù)據(jù)（這當(dāng)然不是說(shuō)視圖永遠(yuǎn)不存儲(chǔ)它所顯示的數(shù)據(jù)。由于性能上的原因，視圖可能對(duì)數(shù)據(jù)進(jìn)行緩存，或使用類似的技巧）。一個(gè)視圖對(duì)象可能負(fù)責(zé)顯示模型對(duì)象的一部分或全部，甚至是很多不同的模型對(duì)象。視圖對(duì)象可能有很多變化。

視圖對(duì)象應(yīng)該盡可能可重用和可配置，它們可以在不同的應(yīng)用程序中提供一致的顯示。在Cocoa中，Application Kit定義了大量的視圖對(duì)象，其中很多對(duì)象都出現(xiàn)在Interface Builder的選盤(pán)上。您可以通過(guò)重用Application Kit的視圖對(duì)象，比如NSButton對(duì)象，來(lái)保證應(yīng)用程序中的按鍵和其它Cocoa應(yīng)用程序的按鍵行為是一樣的，從而保證不同的應(yīng)用程序在外觀和行為上具有高度的一致性。

視圖必須正確地顯示模型，因此需要知道模型發(fā)生的改變。由于模型對(duì)象不應(yīng)該依賴于特定的視圖對(duì)象，所以需要有一個(gè)一般性的方式來(lái)指示模型對(duì)象發(fā)生了變化。

控制器對(duì)象連接模型和視圖

控制器對(duì)象是應(yīng)用程序的視圖對(duì)象和模型對(duì)象之間的協(xié)調(diào)者。通常情況下，它們負(fù)責(zé)保證視圖可以訪問(wèn)其顯示的模型，并充當(dāng)交流的管道，使視圖可以了解模型發(fā)生的變化。控制器對(duì)象也可以為應(yīng)用程序執(zhí)行配置和協(xié)調(diào)的任務(wù)，管理其它對(duì)象的生命周期。

在一個(gè)典型的Cocoa MVC設(shè)計(jì)中，當(dāng)用戶通過(guò)某個(gè)視圖對(duì)象輸入一個(gè)值或做出一個(gè)選擇時(shí)，該值或選擇會(huì)傳遞給控制器對(duì)象。控制器對(duì)象可能以應(yīng)用程序特有的方式對(duì)用戶輸入進(jìn)行解釋，然后或者告訴模型對(duì)象如何處理這個(gè)輸入—比如“增加一個(gè)新值”或“刪除當(dāng)前記錄”，或者使模型對(duì)象在其某個(gè)屬性上反應(yīng)被改變的值。基于同樣的用戶輸入，一些控制器對(duì)象也可以通知相應(yīng)的視圖對(duì)象改變其外觀或行為的某個(gè)部分，比如禁用某個(gè)按鍵。反過(guò)來(lái)，當(dāng)一個(gè)模型對(duì)象發(fā)生變化了—比如加入一個(gè)新的數(shù)據(jù)源—模型對(duì)象通常將變化通知控制器對(duì)象，由控制器對(duì)象要求一或多個(gè)視圖對(duì)象進(jìn)行相應(yīng)的更新。

控制器對(duì)象可能是可重用的，也可能是不可重用的，取決于它們的一般類型。"Cocoa控制器對(duì)象的類型"部分描述Cocoa中不同類型的控制器對(duì)象。

組合角色

我們可以將多個(gè)MVC角色組合起來(lái)，使一個(gè)對(duì)象同時(shí)充當(dāng)多個(gè)角色，比如同時(shí)充當(dāng)控制器和視圖對(duì)象的角色—在這種情況下，該對(duì)象被稱為視圖-控制器。同樣地，您也可以有模型-控制器對(duì)象。對(duì)于某些應(yīng)用程序，象這樣的角色組合是可接收的設(shè)計(jì)。

模型-控制器是主要關(guān)注模型層的控制器。它“擁有”模型，主要責(zé)任是管理模型，并和視圖對(duì)象進(jìn)行交流。應(yīng)用到整個(gè)模型的動(dòng)作方法通常在模型-控制器中實(shí)現(xiàn)。文檔架構(gòu)為您提供了一些這樣的方法；比如說(shuō)，NSDocument對(duì)象（文檔架構(gòu)的核心部分）會(huì)自動(dòng)處理和保存文件相關(guān)的動(dòng)作方法。

視圖控制器是主要關(guān)注視圖層的控制器。它“擁有”界面（視圖），主要責(zé)任是管理界面，并和模型對(duì)象進(jìn)行交流。和視圖顯示的數(shù)據(jù)相關(guān)的動(dòng)作方法通常在視圖控制器中實(shí)現(xiàn)。NSWindowController對(duì)象（也是文檔架構(gòu)的核心部分）就是視圖控制器的一個(gè)例子。

"MVC應(yīng)用程序設(shè)計(jì)指南"中提供一些關(guān)于MVC組合角色對(duì)象的設(shè)計(jì)建議。

進(jìn)一步閱讀：基于文檔的應(yīng)用程序概述從另一個(gè)角度討論模型控制器和視圖控制器之間的區(qū)別。

Cocoa控制器對(duì)象的類型

"控制器對(duì)象連接模型和視圖"部分粗略介紹了控制器對(duì)象的抽象框架，但是在實(shí)踐中的情景要復(fù)雜得多。在Cocoa中有兩種一般類型的控制器對(duì)象：仲裁控制器和協(xié)調(diào)控制器。每種類型的控制器對(duì)象都和一組不同的類相關(guān)聯(lián)，并提供不同的行為。

仲裁控制器通常是從NSController類繼承而來(lái)的對(duì)象。在Cocoa綁定技術(shù)中使用了這種對(duì)象。它們負(fù)責(zé)為視圖和模型對(duì)象之間的數(shù)據(jù)流提供仲裁或支持。

仲裁控制器通常都是已經(jīng)準(zhǔn)備好了，可以直接從Interface Builder選盤(pán)中直接拖出。您可以對(duì)這些對(duì)象進(jìn)行配置，以在視圖和控制器對(duì)象的屬性之間、進(jìn)而在控制器屬性和模型對(duì)象的具體屬性之間建立綁定關(guān)系。結(jié)果，當(dāng)用戶改變視圖對(duì)象顯示的值時(shí)，新的值就會(huì)通過(guò)仲裁控制器自動(dòng)傳遞給模型對(duì)象；而當(dāng)模型的屬性值發(fā)生變化時(shí)，那些變化又會(huì)傳遞給視圖對(duì)象。NSController抽象類及其具體子類—NSObjectController、NSArrayController、NSUserDefaultsController、和NSTreeController—提供了諸如提交和丟棄改變的能力，還可以管理選擇和占位值的特性。

協(xié)調(diào)控制器通常是一個(gè)NSWindowController或NSDocumentController對(duì)象，或者是一個(gè)NSObject定制子類的實(shí)例。它在應(yīng)用程序中的角色是檢查（或者協(xié)調(diào)）整個(gè)或部分應(yīng)用程序是否正常工作，比如從一個(gè)nib文件解檔出來(lái)的對(duì)象是否有效。協(xié)調(diào)控制器提供如下服務(wù)：

響應(yīng)委托消息和對(duì)通告進(jìn)行觀察

響應(yīng)動(dòng)作消息

管理自己“擁有”的對(duì)象的生命周期（比如在正確的時(shí)間釋放那些對(duì)象）

建立對(duì)象間的連接，并執(zhí)行其它配置任務(wù)

NSWindowController和NSDocumentController類是Cocoa為基于文檔的應(yīng)用程序定義的架構(gòu)的一部分。這些類的實(shí)例為上面列出的幾種服務(wù)提供了缺省的實(shí)現(xiàn)，您也可以通過(guò)創(chuàng)建它們的子類來(lái)實(shí)現(xiàn)更為具體的應(yīng)用程序行為，甚至可以用NSWindowController對(duì)象來(lái)管理不基于文檔架構(gòu)的應(yīng)用程序窗口。

協(xié)調(diào)控制器通常擁有nib文件中的對(duì)象，比如File’s Owner對(duì)象，它不屬于nib文件包含的對(duì)象，但負(fù)責(zé)管理nib文件中的對(duì)象。它擁有的對(duì)象包括仲裁控制器、協(xié)調(diào)控制器、和視圖對(duì)象。如果需要進(jìn)一步了解File's Owner及類似的協(xié)調(diào)控制器的更多信息，請(qǐng)參見(jiàn)"MVC是一個(gè)復(fù)合的設(shè)計(jì)模式" 部分的內(nèi)容。

NSObject的定制子類的實(shí)例可能完全適合用作協(xié)調(diào)控制器。這種類型的控制器對(duì)象既有仲裁的功能，也有協(xié)調(diào)的功能。在仲裁行為方面，它們通過(guò)象目標(biāo)-動(dòng)作、插座變量、委托、和通告機(jī)制來(lái)實(shí)現(xiàn)視圖和模型對(duì)象之間的數(shù)據(jù)移動(dòng)。它們有可能包含很多“膠水”代碼，由于那些代碼只用于特定的應(yīng)用程序，所以它們是應(yīng)用程序中最不可能被重用的對(duì)象。

進(jìn)一步閱讀：如果您需要進(jìn)一步了解控制器對(duì)象作為仲裁者的角色，請(qǐng)參見(jiàn)"仲裁者"設(shè)計(jì)模式的信息；如果需要進(jìn)一步了解Cocoa綁定技術(shù)的信息。

#p#

MVC是一個(gè)復(fù)合的設(shè)計(jì)模式

模型-視圖-控制器是一個(gè)組合了幾個(gè)更為基本的設(shè)計(jì)模式的復(fù)合設(shè)計(jì)模式。這些基本的模式一起定義了MVC應(yīng)用程序中特有的功能分割和通信路徑。但是和Cocoa相比，傳統(tǒng)意義上的MVC使用了不同的基本模式，主要表現(xiàn)在應(yīng)用程序的控制器和視圖對(duì)象的不同作用上。

在原來(lái)的（Smalltalk）概念上，MVC是由合成（Composite）、策略（Strategy）、和觀察者（Observer）模式組成的。

合成模式：應(yīng)用程序中的視圖對(duì)象實(shí)際上是一些嵌套視圖的集合，這些視圖以一種協(xié)調(diào)過(guò)的方式（也就是視圖層次結(jié)構(gòu)）在一起工作。這些顯示組件包括窗口、復(fù)合視圖（比如表視圖）、以及單獨(dú)的視圖（比如按鍵）。用戶輸入和顯示可以在復(fù)合結(jié)構(gòu)的任意級(jí)別上進(jìn)行。

策略模式：一個(gè)控制器對(duì)象負(fù)責(zé)實(shí)現(xiàn)一或多個(gè)視圖對(duì)象的策略。視圖對(duì)象將自己限制在視覺(jué)效果的維護(hù)上，而將與應(yīng)用程序具體界面行為有關(guān)的全部決策委托給控制器。

觀察者模式：模型對(duì)象將狀態(tài)的變化通知應(yīng)用程序中感興趣的對(duì)象（通常是視圖對(duì)象）。

這些模式以圖4-4所示的方式協(xié)同工作：用戶操作視圖層次中某個(gè)級(jí)別的視圖，結(jié)果產(chǎn)生一個(gè)事件。控制器對(duì)象接收到這個(gè)事件，并根據(jù)應(yīng)用程序的具體邏輯對(duì)其進(jìn)行解釋－也就是說(shuō)，它應(yīng)用了某種策略。這個(gè)策略可以是請(qǐng)求（通過(guò)消息）模型對(duì)象改變其狀態(tài)，也可以是請(qǐng)求視圖對(duì)象（位于視圖結(jié)構(gòu)的某個(gè)級(jí)別上）改變其行為或外觀。反過(guò)來(lái)，模型對(duì)象在狀態(tài)發(fā)生變化時(shí)會(huì)通知注冊(cè)為觀察者的所有對(duì)象，如果觀察者是個(gè)視圖對(duì)象，則可能會(huì)因此更新外觀。

圖4-4  傳統(tǒng)版本的MVC是一個(gè)復(fù)合設(shè)計(jì)模式

Cocoa版本的MVC也是一種復(fù)合模式，和傳統(tǒng)版本有一些類似之處。事實(shí)上，基于圖4-4的框圖構(gòu)建一個(gè)可以工作的應(yīng)用程序是完全可能的。通過(guò)使用綁定技術(shù)，您很容易就可以創(chuàng)建一個(gè)Cocoa的MVC程序，讓程序中的視圖對(duì)象直接觀察模型對(duì)象，以接收狀態(tài)的改變。然而這個(gè)設(shè)計(jì)有個(gè)理論上的問(wèn)題。視圖對(duì)象和模型對(duì)象應(yīng)該是程序中***可重用性的對(duì)象。視圖對(duì)象代表操作系統(tǒng)及操作系統(tǒng)支持的應(yīng)用程序的“觀感”；外觀和行為的一致性是很重要的，這就要求對(duì)象是高度可重用的。顧名思義，模型對(duì)象負(fù)責(zé)對(duì)問(wèn)題域的關(guān)聯(lián)數(shù)據(jù)進(jìn)行封裝，以及執(zhí)行相關(guān)的操作。從設(shè)計(jì)的角度上看，***讓模型對(duì)象和視圖對(duì)象彼此分離，因?yàn)檫@樣可以增加它們的可重用性。

在大多數(shù)Cocoa應(yīng)用程序中，模型對(duì)象的狀態(tài)變化通告是通過(guò)控制器對(duì)象傳遞給視圖對(duì)象的。圖4-5顯示了這種不同的機(jī)制，盡管多用了兩個(gè)基本設(shè)計(jì)模式，這種通訊機(jī)制顯得清晰很多。

圖4-5  Cocoa版本的MVC也是一個(gè)復(fù)合設(shè)計(jì)模式

在這種復(fù)合模式中，控制器對(duì)象結(jié)合了仲裁者模式和策略模式，對(duì)模型和視圖對(duì)象之間的數(shù)據(jù)流實(shí)施雙向協(xié)調(diào)。模型狀態(tài)的變化通過(guò)應(yīng)用程序的控制器對(duì)象傳遞給視圖對(duì)象。此外，視圖對(duì)象在目標(biāo)-動(dòng)作機(jī)制上采納了命令模式。

請(qǐng)注意：目標(biāo)-動(dòng)作機(jī)制使視圖對(duì)象可以和用戶輸入或選擇進(jìn)行通訊，這種機(jī)制可以在協(xié)調(diào)或仲裁控制器中實(shí)現(xiàn)。但是，機(jī)制的設(shè)計(jì)在不同類型的控制器中也有所不同。對(duì)于協(xié)調(diào)控制器，您可以在Interface Builder中將視圖對(duì)象連接到它的目標(biāo)（即控制器對(duì)象）上，并為其指定動(dòng)作選擇器，動(dòng)作選擇器必須遵循特定的簽名格式。通過(guò)成為窗口和全局應(yīng)用程序?qū)ο蟮奈校瑓f(xié)調(diào)控制器也可以進(jìn)入響應(yīng)者鏈。仲裁控制器使用的綁定機(jī)制也是將視圖對(duì)象和目標(biāo)連接起來(lái)，并允許動(dòng)作方法的簽名攜帶可變數(shù)量、任意類型的參數(shù)。但是仲裁控制器不在響應(yīng)者鏈上。

圖4-5描述的是改良后的復(fù)合設(shè)計(jì)模式，對(duì)其進(jìn)行改良既有實(shí)踐上的原因，也有理論上的原因，特別是在使用仲裁者模式的時(shí)候。仲裁控制器是從NSController的具體子類派生而來(lái)的，除了實(shí)現(xiàn)仲裁者模式之外，這些類還提供很多應(yīng)用程序應(yīng)該加以利用的功能，比如選擇和占位值的管理。如果您不喜歡使用綁定技術(shù)，則您的視圖對(duì)象可以使用象Cocoa通告中心這樣的機(jī)制來(lái)接收模型對(duì)象的通告。但是這要求您創(chuàng)建一個(gè)定制的視圖子類，以便處理模型對(duì)象發(fā)出的通告。

在一個(gè)設(shè)計(jì)良好的Cocoa MVC程序中，協(xié)調(diào)控制器對(duì)象常常“擁有”歸檔到nib文件的仲裁控制器。圖4-6顯示了這兩種控制器類型之間的關(guān)系。

圖4-6 協(xié)調(diào)控制器作為nib文件的擁有者

MVC應(yīng)用程序的設(shè)計(jì)原則

在設(shè)計(jì)應(yīng)用程序的模型-視圖-控制器時(shí)，可以應(yīng)用下面這些指導(dǎo)原則：

雖然您可以使用NSObject定制子類的實(shí)例來(lái)作為仲裁控制器，但是沒(méi)有理由重新實(shí)現(xiàn)一個(gè)仲裁控制器。相反，您可以使用已經(jīng)準(zhǔn)備好的、為Cocoa綁定技術(shù)設(shè)計(jì)的NSController對(duì)象。也就是說(shuō)，使用NSObjectController、NSArrayController、NSUserDefaultsController、或者NSTreeController實(shí)例－或者使用這些NSController具體子類的定制子類的實(shí)例來(lái)作為仲裁控制器。

然而如果應(yīng)用程序很簡(jiǎn)單，而且您對(duì)使用插座變量和目標(biāo)-動(dòng)作機(jī)制來(lái)編寫(xiě)仲裁行為所需要的“膠水代碼”感覺(jué)更好的話，也可以使用NSObject定制子類的實(shí)例來(lái)作為仲裁控制器。在NSObject的定制子類中，您也可以以NSController的方式來(lái)實(shí)現(xiàn)仲裁控制器，使用鍵-值編碼、鍵-值觀察、以及編輯器協(xié)議。

雖然您可以把不同的MVC角色合并在一個(gè)對(duì)象中，但是，在總體上***的策略還是保持角色的分離。這可以增強(qiáng)對(duì)象的可重用性以及使用這些對(duì)象的程序的可擴(kuò)展性。如果您要把不同的MVC角色合并到一個(gè)類中，則首先為該類選擇一個(gè)主要的角色，然后（為了便于維護(hù)）在相同的實(shí)現(xiàn)文件中使用范疇來(lái)進(jìn)行擴(kuò)展，使其具有其它角色的作用。

設(shè)計(jì)良好的MVC應(yīng)用程序的目標(biāo)之一應(yīng)該是盡可能多地使用（至少在理論上）可重用的對(duì)象。特別重要的是，視圖對(duì)象和模型對(duì)象應(yīng)該是高度可重用的（當(dāng)然，那些準(zhǔn)備好的仲裁控制器對(duì)象也都是可重用的）。應(yīng)用程序的具體行為通常盡可能多地集中在控制器對(duì)象中。

雖然讓視圖直接觀察模型并檢測(cè)狀態(tài)的變化是可能的，但是這并不是推薦的做法。視圖對(duì)象應(yīng)該總是通過(guò)仲裁控制器對(duì)象來(lái)了解模型對(duì)象的變化。這有兩層意義：

如果您使用綁定機(jī)制來(lái)使視圖對(duì)象直接觀察模型對(duì)象的屬性，那么您就忽視了NSController及其子類為應(yīng)用程序提供的各種好處：選擇和占位符的管理，還有提交和丟棄修改的能力。

如果您不使用綁定機(jī)制，則必須從現(xiàn)有的視圖類派生出子類，并加入處理模型對(duì)象發(fā)出的狀態(tài)變化通告的能力。

努力限制應(yīng)用程序中類代碼的依賴關(guān)系。一個(gè)類對(duì)另一個(gè)類的依賴越大，就越不具有重用性。具體的推薦規(guī)則和兩個(gè)類在MVC中的角色有關(guān)：

視圖對(duì)象不應(yīng)依賴于模型對(duì)象（雖然對(duì)于某些定制視圖來(lái)說(shuō)可能是不可避免的）。

視圖類不必然依賴于仲裁控制器類。

模型類不應(yīng)該依賴于除了其它模型類之外的類。

協(xié)調(diào)控制器不應(yīng)該依賴于模型類（和視圖相似，雖然對(duì)某些定制的控制器類來(lái)說(shuō)，這種依賴關(guān)系是必須的。）

仲裁控制器類不應(yīng)該依賴于視圖類或協(xié)調(diào)控制器類。

協(xié)調(diào)控制器類依賴于所有MVC類。

如果Cocoa提供的架構(gòu)已經(jīng)將MVC角色分配給具體類型的對(duì)象，則直接使用該架構(gòu)。這樣做可以使您更為容易地將工程的各個(gè)組件集成在一起。文檔架構(gòu)就是這樣的一個(gè)例子，它包括一個(gè)Xcode工程模板，并在模板中將NSDocument對(duì)象（基于nib的控制器模型）預(yù)先配置為File's Owner。

Cocoa中的模型-視圖-控制器

模型-視圖-控制器設(shè)計(jì)模式使很多Cocoa機(jī)制和技術(shù)的基礎(chǔ)。因此，在面向?qū)ο蟮脑O(shè)計(jì)中使用MVC的重要性已經(jīng)超過(guò)了如何在自己的應(yīng)用程序中得到更好的可重用性和可擴(kuò)展性。如果您的應(yīng)用程序要使用基于MVC的Cocoa技術(shù)，則***它本身也是遵循MVC模式。如果您的應(yīng)用程序很好地進(jìn)行MVC的分離，在使用這些技術(shù)時(shí)就應(yīng)該會(huì)相對(duì)簡(jiǎn)單一些；相反，如果沒(méi)有好的分離，則需要花費(fèi)更多的努力。

Cocoa框架中包含下面這些基于模型-視圖-控制器的架構(gòu)、機(jī)制、和技術(shù)：

文檔架構(gòu)。在這個(gè)架構(gòu)中，一個(gè)基于文檔的應(yīng)用程序由一個(gè)應(yīng)用程序級(jí)別的控制器對(duì)象（NSDocumentController）組成的，每個(gè)文檔窗口都有一個(gè)控制器對(duì)象（NSWindowController），每個(gè)文檔（NSDocument）都有一個(gè)結(jié)合了控制器和模型角色的對(duì)象。

綁定技術(shù)。 在之前的討論中曾經(jīng)提到過(guò)，MVC是Cocoa綁定技術(shù)的核心。NSController抽象類的具體子類提供了一些準(zhǔn)備好的控制器對(duì)象，您可以對(duì)它們進(jìn)行配置，建立視圖對(duì)象和模型對(duì)象屬性之前的綁定關(guān)系。

應(yīng)用程序的腳本能力。在設(shè)計(jì)應(yīng)用程序并使其可以支持腳本控制的時(shí)候，不僅需要遵循MVC設(shè)計(jì)模式，而且需要正確設(shè)計(jì)應(yīng)用程序的模型對(duì)象。訪問(wèn)應(yīng)用程序狀態(tài)和請(qǐng)求應(yīng)用程序行為的腳本命令通常應(yīng)該發(fā)送給模型對(duì)象或者控制器對(duì)象。

Core Data。Core Data框架負(fù)責(zé)管理模型對(duì)象圖，以及將模型對(duì)象存儲(chǔ)到一個(gè)持久的倉(cāng)庫(kù)（還有從倉(cāng)庫(kù)中取出），以確保這些對(duì)象的持久性。Core Data和Cocoa的綁定技術(shù)緊密結(jié)合在一起。MVC和對(duì)象建模模式是Core Data架構(gòu)的基本決定因素。

Undo。在Undo架構(gòu)中，模型對(duì)象又一次發(fā)揮中心的作用。模型對(duì)象的基元方法（常常是它的存取方法）通常是實(shí)現(xiàn)undo和redo操作的地方。某個(gè)動(dòng)作的視圖和控制器對(duì)象也可能參與這些操作。舉例來(lái)說(shuō)，您可能有一個(gè)方法負(fù)責(zé)處理undo和redo菜單項(xiàng)的標(biāo)題，或者undo一個(gè)文本視圖中的選擇操作。

小結(jié)：Cocoa模型 視圖 控制器設(shè)計(jì)模式的內(nèi)容介紹完了，希望本文對(duì)你有所幫助！