iOS中MVC設計模式，iOSMVC設計模式

iOS中MVC設計模式，iOSMVC設計模式
        在組織大型項目的代碼檔案時，我們常用MVC的思想。MVC的概念講起來非常簡單，就和對象（object）一樣。但是理解和應用起來卻非常困難。今天我們就簡單總結一下MVC設計理念。 

MVC(Model View Controller)模型(model)－視圖(view)－控制器(controller)：
MVC本來是存在於Desktop程式中的，M是指資料模型，V是指使用者介面，C則是控制器。使用MVC是將M和V的實現代碼分離，從而使同一個程式可以使用不同的表現形式。比如一批統計資料你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新，從例子可以看出MVC就是Observer設計模式的一個特例。

MVC是一個設計模式，它強制性的使應用程式的輸入、處理和輸出分開。使用MVC應用程式被分成三個核心組件：模型、視圖、控制器。它們各自處理自己的任務。分層概念

 （一）模型對象
模型對象封裝了應用程式的資料，並定義操控和處理該資料的邏輯和運算。例如，模型對象可能是表示遊戲中的角色或地址簿中的連絡人。使用者在視圖層中所進行的建立或修改資料的操作，通過控制器對象傳達出去，最終會建立或更新模型對象。模型對象更改時（例如通過網路連接接收到新資料），它通知控制器對象，控制器對象更新相應的視圖對象。在MVC的三個組件中，模型擁有最多的處理任務。例如它可能用象EJBs和ColdFusion Components這樣的構件對象來處理資料庫。被模型返回的資料是中立的，就是說模型與資料格式無關，這樣一個模型能為多個視圖提供資料。由於應用於模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重複性。

 

（二）視圖對象
視圖對象是應用程式中使用者可以看見的對象。視圖對象知道如何將自己繪製出來，並可能對使用者的操作作出響應。視圖對象的主要目的，就是顯示來自應用程式模型對象的資料，並使該資料可被編輯。儘管如此，在 MVC 應用程式中，視圖對象通常與模型對象分離。在iOS應用程式開發中，所有的控制項、視窗等都繼承自 UIView，對應MVC中的V。UIView及其子類主要負責UI的實現，而UIView所產生的事件都可以採用委託的方式，交給UIViewController實現。

 

（三）控制器對象
在應用程式的一個或多個視圖對象和一個或多個模型對象之間，控制器對象充當媒介。控制器對象因此是同步管道程式，通過它，視圖對象瞭解模型對象的更改，反之亦然。控制器對象還可以為應用程式執行設定和協調任務，並管理其他對象的生命週期。

控制器對象解釋在視圖對象中進行的使用者操作，並將新的或更改過的資料傳達給模型對象。模型對象更改時，一個控制器對象會將新的模型資料傳達給視圖對象，以便視圖對象可以顯示它。

為什麼要使用 MVC
　  首先，最重要的一點是多個視圖能共用一個模型，現在需要用越來越多的方式來訪問你的應用程式。對此，其中一個解決之道是使用MVC，無論你的使用者想要Flash介面或是 WAP 介面；用一個模型就能處理它們。由於你已經將資料和商務規則從展示層分開，所以你可以最大化的重用你的代碼了。
　　由於模型返回的資料沒有進行格式化，所以同樣的構件能被不同介面使用。例如，很多資料可能用HTML來表示，但是它們也有可能要用Adobe Flash和WAP來表示。模型也有狀態管理和資料持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線連網的應用程式所重用。
　　因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程式的資料層和商務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS資料來源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的資料來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程式的三個組件是相互獨立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松耦合的構件。
　　對我來說，控制器也提供了一個好處，就是可以使用控制器來聯結不同的模型和視圖去完成使用者的需求，這樣控制器可以為構造應用程式提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據使用者的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給使用者。
MVC的優點
（一）、低耦合性
　　視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的商務程序或者商務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程式的資料層和商務規則。

（二）、高重用性和可適用性
　　隨著技術的不斷進步，現在需要用越來越多的方式來訪問應用程式。MVC模式允許你使用各種不同樣式的視圖來訪問同一個伺服器端的代碼。它包括任何WEB（HTTP）瀏覽器或者無線瀏覽器（wap），比如，使用者可以通過電腦也可通過手機來訂購某樣產品，雖然訂購的方式不一樣，但處理訂購產品的方式是一樣的。由於模型返回的資料沒有進行格式化，所以同樣的構件能被不同的介面使用。例如，很多資料可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的命令是改變視圖層的實現方式，而控制層和模型層無需做任何改變。

（三）、較低的生命週期成本
　　MVC使開發和維護使用者介面的技術含量降低。

 

（四）、可維護性
　　分離視圖層和商務邏輯層也使得應用更易於維護和修改。

（五）、有利於軟體工程化管理
　　由於不同的層各司其職，每一層不同的應用具有某些相同的特徵，有利於通過工程化、工具化管理程式碼。

MVC的缺點：
　　MVC的缺點是由於它沒有明確的定義，所以完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。
　　你將不得不花費相當可觀的時間去考慮如何將MVC運用到你的應用程式，同時由於模型和視圖要嚴格的分離，這樣也給調試應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。一旦你的構件經過了測試，你就可以毫無顧忌的重用它們了。
　　根據開發人員經驗，由於開發人員將一個應用程式分成了三個組件，所以使用MVC同時也意味著你將要管理比以前更多的檔案，這一點是顯而易見的。這樣好像我們的工作量增加了，但是請記住這比起它所能帶給我們的好處是不值一提。
　　MVC並不適合小型甚至中等規模的應用程式，花費大量時間將MVC應用到規模並不是很大的應用程式通常會得不償失。
　　MVC設計模式是一個很好建立軟體的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、視圖和控制器的構件，你可能需要重新思考你的應用程式，尤其是應用程式的構架方面。如果你肯接受MVC，並且有能力應付它所帶來的額外的工作和複雜性，MVC將會使你的軟體在健壯性，代碼重用和結構方面上一個新的台階。

IOS MVC設計模式：

 

  

圖中有幾條線把這三部分劃分開，有黃線，虛線，和白色的實線。我們把它們想象成路標。你可以看到，在M和V之間有兩條黃線，這表示什麼呢？它意味著你不能 穿越這黃線，任何一個方向都不行，即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之間有直接的聯絡，這 也是在它們兩之間有兩根黃線的原因。 總結下來也就是以下三點：

（1）、Model和View永遠不能相互連信，只能通過Controller傳遞。

（2）、Controller可以直接與Model對話（讀寫調用Model），Model通過Notification和KVO機制與Controller間接通訊。

（3）、Controller可以直接與View對話，通過outlet,直接操作View,outlet直接對應到View中的控制項,View通過action向Controller報告事件的發生(如使用者Touch我了)。Controller是View的直接資料來源（資料很可能是Controller從Model中取得並經過加工了）。Controller是View的代理（delegate),以同步View與Controller。

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

對於不同的UIView，有相應的UIViewController，對應MVC中的C。例如在iOS上常用的UITableView，它所對應的Controller就是UITableViewController。