iOS裡的MVC

iOS裡的MVC

我們今天談談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

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

 

 

http://hi.baidu.com/janins/blog/item/1828a9f82f90509bb901a0d0.html?

相信說起MVC（Model－View－Controller）大家都很熟悉。在iOS開發中MVC的機制被使用的淋漓盡致，並且我覺得在iOS上寫程式，充分理解iOS的MVC模式，有助於我們程式的組織合理性，相反，我們不遵守MVC的一些約定，程式是可以寫的，但就等著受苦了。

下面我只對一些約定列一個表，並且說一下iOS的支援機制啊，算分享給大家：

1、Model不允許和Controller，View打交道。也就是Model根本不知道誰會用自己，Model中不能有任何對Controller和View的引用。正所謂：Don't call me, I will call you.就是給Model設計說的。我們再想想，在一般程式中Model到處被拿去用，它要維護到底誰用真的很難。那你會問：兄弟，那當Model的資料變了，我怎麼通知視圖更新呢？這裡常用的機制就是廣播模式，或者電台模式，或者事件機制都行。在iOS中有兩種支援機制：Notification和KVO（Key-Value
Observing）。這兩種東西原理差不多，KVO是iOS中的一個核心概念，簡單理解就是：關注Model某個資料（Key）的對象可以註冊為監聽器，一旦Model某個Key的Value發生變化，就會廣播給所有的監聽器。這和Flex，JavaFX中的綁定都是一個道理。

2、View不允許直接引用Controller和Model，它很專一地被Controller控制來進行資料的顯示和接收使用者的互動。我們知道View顯示的時候需要資料，我們也知道在View上會產生事件。如果要達到不和Controller，Model直接打交道，就需要機制來支援。在Objective－C中有Protocol的東西，並且提出Delegate（代理模式）就是來解決UIView想和Controller松耦合互動問題的。除了這個外，iOS還提供了Action－Target模式來讓Controller監聽View的事件。那對View如何獲得資料，iOS中提了Data
Source的概念，其實也是Protocol的應用。

3、每一次推給使用者的一個操作螢幕，最好都是MVC的三者組合，不要出現一組以上的MVC組合。