iOS裡的MVC

來源:互聯網
上載者:User

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組合。


相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.