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

模型-視圖-控制器模式（MVC）是一個相當老的設計模式，它的一些變體至少在Smarttalk的早期就出現了。它是一種高級別的模式，關注的是應用程序的全局架構，并根據各種對象在程序中發揮的作用對其進行分類。它也是個復合的模式，因為它是由幾個更加基本的模式組成的。

面向對象的程序在設計上采用MVC模式會帶來幾個方面的好處。這種程序中的很多對象可能更具重用性，它們的接口也可能定義得更加良好。程序從總體上更加適應需求的改變—換句話說，它們比不基于MVC的程序更加容易擴展。而且，Cocoa中的很多技術和架構—比如綁定技術、文檔架構、和腳本技術—都基于MVC，而且要求您的定制對象充當MVC定義的某種角色。

MVC對象的作用和關系

MVC設計模式考慮三種對象：模型對象、視圖對象、和控制器對象。模式定義了這三種對象在應用程序中充當的角色，以及它們的通訊路徑。在設計應用程序時，一個主要的步驟就是進行這三種對象的選擇－或者說為這三種對象創建定制類。三種對象中的每一種都和其它兩種按抽象的邊界區分，并和其它兩種對象進行跨邊界的通訊。

模型對象負責包裝數據和基本行為

模型對象代表特別的知識和專業技能，它們負責保有應用程序的數據和定義操作數據的邏輯。一個定義良好的MVC應用程序會將所有重要的數據封裝在模型對象中。任何代表應用程序留存狀態的數據（無論該狀態存儲在文件中，還是存儲在數據庫中），一旦載入應用程序，就應該駐留在模型對象中。因為它們代表與特定問題域有關的知識和專業技能，所以有可能被重用。

在理想情況下，模型對象不和負責表示與編輯模型數據的用戶界面建立顯式的連接。舉例來說，如果有個代表一個人的模型對象（假定您在編寫一個地址本），您可能希望存儲這個人的生日，則將生日存儲在您的Person模型對象是比較好的做法。但是，日期格式字符串或其它有關日期如何表示的信息可能存儲在別的地方比較好。

在實踐上，這種分隔并不總是***的，這里有一定的靈活空間。但一般來說，模型對象不應該關心界面和表示的問題。一個具有合理例外的例子是描畫程序，它的模型對象代表要顯示的圖形。圖形對象知道如何描畫自身是合理的，因為它們存在的主要原因就是為了定義視覺上的信息。但是即使在這種情況下，圖形對象也不應該完全依賴于特定的視圖，它們不應該負責描畫的具體位置，而應該由希望表示這些圖形對象的視圖對象發出描畫的請求。

進一步閱讀：模型對象實現指南文檔種討論模型對象的正確設計和實現。

視圖對象負責向用戶表示信息

視圖對象知道如何顯示應用程序的模型數據，而且可能允許用戶對其進行編輯。視圖對象不應該負責存儲它所顯示的數據（這當然不是說視圖永遠不存儲它所顯示的數據。由于性能上的原因，視圖可能對數據進行緩存，或使用類似的技巧）。一個視圖對象可能負責顯示模型對象的一部分或全部，甚至是很多不同的模型對象。視圖對象可能有很多變化。

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

視圖必須正確地顯示模型，因此需要知道模型發生的改變。由于模型對象不應該依賴于特定的視圖對象，所以需要有一個一般性的方式來指示模型對象發生了變化。

控制器對象連接模型和視圖

控制器對象是應用程序的視圖對象和模型對象之間的協調者。通常情況下，它們負責保證視圖可以訪問其顯示的模型，并充當交流的管道，使視圖可以了解模型發生的變化。控制器對象也可以為應用程序執行配置和協調的任務，管理其它對象的生命周期。

在一個典型的Cocoa MVC設計中，當用戶通過某個視圖對象輸入一個值或做出一個選擇時，該值或選擇會傳遞給控制器對象?？刂破鲗ο罂赡芤詰贸绦蛱赜械姆绞綄τ脩糨斎脒M行解釋，然后或者告訴模型對象如何處理這個輸入—比如“增加一個新值”或“刪除當前記錄”，或者使模型對象在其某個屬性上反應被改變的值?；谕瑯拥挠脩糨斎?，一些控制器對象也可以通知相應的視圖對象改變其外觀或行為的某個部分，比如禁用某個按鍵。反過來，當一個模型對象發生變化了—比如加入一個新的數據源—模型對象通常將變化通知控制器對象，由控制器對象要求一或多個視圖對象進行相應的更新。

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

組合角色

我們可以將多個MVC角色組合起來，使一個對象同時充當多個角色，比如同時充當控制器和視圖對象的角色—在這種情況下，該對象被稱為視圖-控制器。同樣地，您也可以有模型-控制器對象。對于某些應用程序，象這樣的角色組合是可接收的設計。

模型-控制器是主要關注模型層的控制器。它“擁有”模型，主要責任是管理模型，并和視圖對象進行交流。應用到整個模型的動作方法通常在模型-控制器中實現。文檔架構為您提供了一些這樣的方法；比如說，NSDocument對象（文檔架構的核心部分）會自動處理和保存文件相關的動作方法。

視圖控制器是主要關注視圖層的控制器。它“擁有”界面（視圖），主要責任是管理界面，并和模型對象進行交流。和視圖顯示的數據相關的動作方法通常在視圖控制器中實現。NSWindowController對象（也是文檔架構的核心部分）就是視圖控制器的一個例子。

"MVC應用程序設計指南"中提供一些關于MVC組合角色對象的設計建議。

進一步閱讀：基于文檔的應用程序概述從另一個角度討論模型控制器和視圖控制器之間的區別。

Cocoa控制器對象的類型

"控制器對象連接模型和視圖"部分粗略介紹了控制器對象的抽象框架，但是在實踐中的情景要復雜得多。在Cocoa中有兩種一般類型的控制器對象：仲裁控制器和協調控制器。每種類型的控制器對象都和一組不同的類相關聯，并提供不同的行為。

仲裁控制器通常是從NSController類繼承而來的對象。在Cocoa綁定技術中使用了這種對象。它們負責為視圖和模型對象之間的數據流提供仲裁或支持。

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

協調控制器通常是一個NSWindowController或NSDocumentController對象，或者是一個NSObject定制子類的實例。它在應用程序中的角色是檢查（或者協調）整個或部分應用程序是否正常工作，比如從一個nib文件解檔出來的對象是否有效。協調控制器提供如下服務：

響應委托消息和對通告進行觀察

響應動作消息

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

建立對象間的連接，并執行其它配置任務

NSWindowController和NSDocumentController類是Cocoa為基于文檔的應用程序定義的架構的一部分。這些類的實例為上面列出的幾種服務提供了缺省的實現，您也可以通過創建它們的子類來實現更為具體的應用程序行為，甚至可以用NSWindowController對象來管理不基于文檔架構的應用程序窗口。

協調控制器通常擁有nib文件中的對象，比如File’s Owner對象，它不屬于nib文件包含的對象，但負責管理nib文件中的對象。它擁有的對象包括仲裁控制器、協調控制器、和視圖對象。如果需要進一步了解File's Owner及類似的協調控制器的更多信息，請參見"MVC是一個復合的設計模式" 部分的內容。

NSObject的定制子類的實例可能完全適合用作協調控制器。這種類型的控制器對象既有仲裁的功能，也有協調的功能。在仲裁行為方面，它們通過象目標-動作、插座變量、委托、和通告機制來實現視圖和模型對象之間的數據移動。它們有可能包含很多“膠水”代碼，由于那些代碼只用于特定的應用程序，所以它們是應用程序中最不可能被重用的對象。

進一步閱讀：如果您需要進一步了解控制器對象作為仲裁者的角色，請參見"仲裁者"設計模式的信息；如果需要進一步了解Cocoa綁定技術的信息。

#p#

MVC是一個復合的設計模式

模型-視圖-控制器是一個組合了幾個更為基本的設計模式的復合設計模式。這些基本的模式一起定義了MVC應用程序中特有的功能分割和通信路徑。但是和Cocoa相比，傳統意義上的MVC使用了不同的基本模式，主要表現在應用程序的控制器和視圖對象的不同作用上。

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

合成模式：應用程序中的視圖對象實際上是一些嵌套視圖的集合，這些視圖以一種協調過的方式（也就是視圖層次結構）在一起工作。這些顯示組件包括窗口、復合視圖（比如表視圖）、以及單獨的視圖（比如按鍵）。用戶輸入和顯示可以在復合結構的任意級別上進行。

策略模式：一個控制器對象負責實現一或多個視圖對象的策略。視圖對象將自己限制在視覺效果的維護上，而將與應用程序具體界面行為有關的全部決策委托給控制器。

觀察者模式：模型對象將狀態的變化通知應用程序中感興趣的對象（通常是視圖對象）。

這些模式以圖4-4所示的方式協同工作：用戶操作視圖層次中某個級別的視圖，結果產生一個事件。控制器對象接收到這個事件，并根據應用程序的具體邏輯對其進行解釋－也就是說，它應用了某種策略。這個策略可以是請求（通過消息）模型對象改變其狀態，也可以是請求視圖對象（位于視圖結構的某個級別上）改變其行為或外觀。反過來，模型對象在狀態發生變化時會通知注冊為觀察者的所有對象，如果觀察者是個視圖對象，則可能會因此更新外觀。

圖4-4  傳統版本的MVC是一個復合設計模式

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

在大多數Cocoa應用程序中，模型對象的狀態變化通告是通過控制器對象傳遞給視圖對象的。圖4-5顯示了這種不同的機制，盡管多用了兩個基本設計模式，這種通訊機制顯得清晰很多。

圖4-5  Cocoa版本的MVC也是一個復合設計模式

在這種復合模式中，控制器對象結合了仲裁者模式和策略模式，對模型和視圖對象之間的數據流實施雙向協調。模型狀態的變化通過應用程序的控制器對象傳遞給視圖對象。此外，視圖對象在目標-動作機制上采納了命令模式。

請注意：目標-動作機制使視圖對象可以和用戶輸入或選擇進行通訊，這種機制可以在協調或仲裁控制器中實現。但是，機制的設計在不同類型的控制器中也有所不同。對于協調控制器，您可以在Interface Builder中將視圖對象連接到它的目標（即控制器對象）上，并為其指定動作選擇器，動作選擇器必須遵循特定的簽名格式。通過成為窗口和全局應用程序對象的委托，協調控制器也可以進入響應者鏈。仲裁控制器使用的綁定機制也是將視圖對象和目標連接起來，并允許動作方法的簽名攜帶可變數量、任意類型的參數。但是仲裁控制器不在響應者鏈上。

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

在一個設計良好的Cocoa MVC程序中，協調控制器對象常常“擁有”歸檔到nib文件的仲裁控制器。圖4-6顯示了這兩種控制器類型之間的關系。

圖4-6 協調控制器作為nib文件的擁有者

MVC應用程序的設計原則

在設計應用程序的模型-視圖-控制器時，可以應用下面這些指導原則：

雖然您可以使用NSObject定制子類的實例來作為仲裁控制器，但是沒有理由重新實現一個仲裁控制器。相反，您可以使用已經準備好的、為Cocoa綁定技術設計的NSController對象。也就是說，使用NSObjectController、NSArrayController、NSUserDefaultsController、或者NSTreeController實例－或者使用這些NSController具體子類的定制子類的實例來作為仲裁控制器。

然而如果應用程序很簡單，而且您對使用插座變量和目標-動作機制來編寫仲裁行為所需要的“膠水代碼”感覺更好的話，也可以使用NSObject定制子類的實例來作為仲裁控制器。在NSObject的定制子類中，您也可以以NSController的方式來實現仲裁控制器，使用鍵-值編碼、鍵-值觀察、以及編輯器協議。

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

設計良好的MVC應用程序的目標之一應該是盡可能多地使用（至少在理論上）可重用的對象。特別重要的是，視圖對象和模型對象應該是高度可重用的（當然，那些準備好的仲裁控制器對象也都是可重用的）。應用程序的具體行為通常盡可能多地集中在控制器對象中。

雖然讓視圖直接觀察模型并檢測狀態的變化是可能的，但是這并不是推薦的做法。視圖對象應該總是通過仲裁控制器對象來了解模型對象的變化。這有兩層意義：

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

如果您不使用綁定機制，則必須從現有的視圖類派生出子類，并加入處理模型對象發出的狀態變化通告的能力。

努力限制應用程序中類代碼的依賴關系。一個類對另一個類的依賴越大，就越不具有重用性。具體的推薦規則和兩個類在MVC中的角色有關：

視圖對象不應依賴于模型對象（雖然對于某些定制視圖來說可能是不可避免的）。

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

模型類不應該依賴于除了其它模型類之外的類。

協調控制器不應該依賴于模型類（和視圖相似，雖然對某些定制的控制器類來說，這種依賴關系是必須的。）

仲裁控制器類不應該依賴于視圖類或協調控制器類。

協調控制器類依賴于所有MVC類。

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

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

模型-視圖-控制器設計模式使很多Cocoa機制和技術的基礎。因此，在面向對象的設計中使用MVC的重要性已經超過了如何在自己的應用程序中得到更好的可重用性和可擴展性。如果您的應用程序要使用基于MVC的Cocoa技術，則***它本身也是遵循MVC模式。如果您的應用程序很好地進行MVC的分離，在使用這些技術時就應該會相對簡單一些；相反，如果沒有好的分離，則需要花費更多的努力。

Cocoa框架中包含下面這些基于模型-視圖-控制器的架構、機制、和技術：

文檔架構。在這個架構中，一個基于文檔的應用程序由一個應用程序級別的控制器對象（NSDocumentController）組成的，每個文檔窗口都有一個控制器對象（NSWindowController），每個文檔（NSDocument）都有一個結合了控制器和模型角色的對象。

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

應用程序的腳本能力。在設計應用程序并使其可以支持腳本控制的時候，不僅需要遵循MVC設計模式，而且需要正確設計應用程序的模型對象。訪問應用程序狀態和請求應用程序行為的腳本命令通常應該發送給模型對象或者控制器對象。

Core Data。Core Data框架負責管理模型對象圖，以及將模型對象存儲到一個持久的倉庫（還有從倉庫中取出），以確保這些對象的持久性。Core Data和Cocoa的綁定技術緊密結合在一起。MVC和對象建模模式是Core Data架構的基本決定因素。

Undo。在Undo架構中，模型對象又一次發揮中心的作用。模型對象的基元方法（常常是它的存取方法）通常是實現undo和redo操作的地方。某個動作的視圖和控制器對象也可能參與這些操作。舉例來說，您可能有一個方法負責處理undo和redo菜單項的標題，或者undo一個文本視圖中的選擇操作。

小結：Cocoa模型 視圖 控制器設計模式的內容介紹完了，希望本文對你有所幫助！