我們今天談談cocoa程式設計中的 模型－檢視－控制器（MVC）範型。我們將從兩大方面來討論MVC：

1. 什麼是MVC？
2. M、V、C之間的交流方式是什麼樣子的？

理解了MVC的概念，對cocoa程式開發是至關重要的。

一、MVC的概念

MVC是Model-VIew-Controller，就是模型－檢視－控制器，這些都是什麼東西呢？

MVC把軟體系統分為三個部分：Model，View，Controller。在cocoa中，你的程式中的每一個object（物件）都將明顯地僅屬於這三部分中的一個，而完全不屬於另外兩個。

Model = 你的程式是什麼(而不是你的程式是如何顯示的)

讓我們舉個例子，我們上中學的時候，我們的步步高電子詞典中有個遊戲叫“雷霆戰機”，也就是“打飛機”的遊戲，Model就是：你的小飛機的攻擊力是多少？你的小飛機上裝的是什麼武器，炮彈，導彈，還是鐳射炮？你的小飛機還有多少血？等等。再概括點說，就是你的程式將要實現的功能，或者是它所能幹的事情。

Controller = 如何使你的模型呈現給使用者(程式邏輯)

Controller是程式內部的邏輯，大多情況下你將看不到它，它將Model和View捆綁在一起，它將處理使用者的輸入，例如，你按開炮的鍵子，Controller就會通過內部的邏輯來處理你的要求，並在螢幕上做出相應的顯示，你將看到螢幕上的小飛機發出炮彈擊中敵機。這也是Controller控制View的顯示的例子。所以你可以把Controller看成是連線M和V的橋樑。

View ＝ 在螢幕上你所看到的（是你的Controller的“奴才”）

接著前面的小飛機，View就是：你的小飛機是什麼樣子的，有一個還是兩個翅膀，有幾挺槍炮；還有，你的飛機在螢幕上的位置等等。總之，你在螢幕上看到的元件都可以歸類為View。

MVC可以幫助確保幫助實現程式最大程度的可重用性。各MVC元素彼此獨立運作，通過分開這些元素，可以構建可維護，可獨立更新的程式組建。

二、M V C之間的交流模式

好了，現在我們來討論MVC中各個元素之間的交流方式。

我們把程式分成三個部分，但並不希望他們完全獨立，因為那樣的話，我們的程式將毫無意義和功能而言。它們之間必然存在某種聯絡，使它們能有機的成為一個整體來實現各種強大的功能。而這種聯絡就是我們提到的交流方式。我們來看看下面的圖，此圖出自斯坦福大學CS193課程的課件。

圖中有幾條線把這三部分劃分開，有黃線，虛線，和白色的實線。我們把它們想象成路標。你可以看到，在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之間有直接的聯絡，這也是在它們兩之間有兩根黃線的原因。

好的應用程式要具備與使用者互動的能力。如果沒有良好的互動性，程式的功能將會受到很大的限制。在MVC中，V是和使用者直接接觸的，使用者看不到M和C，所以，程式與使用者的互動必須通過V來實現，但V只是檢視而已，它並不能完全處理使用者的要求，所以，這就要求V必須有某種手段來向C傳送資訊，移交使用者的互動要求。這手段就是前面白色實線代表的過路費，你知道V不能知道C的一切，但它可以通過某種“手段”來和C進行交流，移交使用者互動責任。

我們接下來討論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來請求資料。

好了，這就是V給C傳送資訊的三種形式。

最後一個問題。你看到M和C之間的白線，這意味著M不可以直接地，沒有限制的對C進行交流。但有時，這個方向的交流是必要的。當M中的一些東西發生變化時，C需要了解這些變化，那我們怎麼才能讓C知道M的變化呢？通知（Notification）和KVO是解決問題的好方法。它們是這樣工作的，當M中的某些東西發生變化時，他們會向C發出通知“嘿，老兄，注意了啊，我這發生變化了”，或者他們會發出指向變化的指標給C，或其他什麼的。總之，他們的工作模式是這樣的。

下面是我們的一個總結，cocoa忠實於MVC，所以理解cocoa的MVC是我們關鍵的開始，希望這些能使你明白一些。

C對M：API
C對V：Outlet
V對C：Target-action， Delegate，Datasource
M對C：Notification，KVO

這篇部落格清楚的說明了MVC的架構，程式碼的組織方式以及三者之間的互動手段

轉載自：http://wangwenhao.net/2011/10/20/mvc-in-ios/