如果你已經開發iOS應用程序有一段時間了，那麼你可能聽說過MVVM或者MVC（設計模式）。這是你構建iOS應用程序的標准模式。然而，最近，我越來越厭倦MVC的一些缺點了。在這篇文章中，我要梳理一下什麼是MVC，及其缺點，並告訴你一個新的方式來組織你的應用程序：（那就是）MVVM。

Model-View-Controller--MVC（模型-視圖-控制器） MVC是通過明確的范例來構造你的代碼，Apple甚至是這麼說的。在MVC模式下，所有的對象被劃分為模型，視圖和控制器。模型存放數據，視圖提供了一個交互式的界面給用戶，視圖控制器協調模型和視圖之間的相互作用。

在圖解裡，視圖作為通知任何用戶交互的控制器。然後視圖控制器更新模型來體現狀態的變化。然後該模型（通常是通過鍵 - 值觀察）通知所有控制器，他們需要對自己的視圖進行更新。這種協調方式構成了很多寫在iOS應用程序裡面的代碼。

模型對象通常是非常，非常簡單的。很多時候，他們是核心數據管理對象，或者，如果你比較喜歡避開核心數據和其他普遍的模型。更具蘋果的說法，模型用包含的數據和邏輯來處理這些數據。在實踐中，模型往往很稀疏，不管這樣是好是壞，控制器得到了模型的邏輯。

視圖（通常情況下）是UIKit組件或者程序員定義的UIKit組件集合其中之一。他們通常拼湊到你的.xib或者.Storyboard中：視覺和應用程序交互的組件。按鈕。標簽。你有一個想法，視圖應該永遠不會被模型直接引用，控制器應該只通過IBAction觸發事件。不屬於視圖本身的業務邏輯不應該在那裡。

就這樣我們捨棄了控制器。控制器是一個應用程序的“粘合劑代碼”：它在模型和視圖之間協調所有的交互，控制器負責管理他們自己視圖的視圖層次結構。他們響應視圖的加載，出現，消失等等。他們傾向於用模型邏輯來裝載，我們避免我們的模型和業務邏輯遠離我們的觀點。這是我們與MVC的第一個問題…

大規模的視圖控制器

因為在視圖控制器中放置的代碼量非常大，他們往往會變得很臃腫，在iOS中有的視圖控制器中的代碼，可能會延展至成千上萬代碼行。你應用程序中這些臃腫的片段權衡下來：大規模的視圖控制器都難以維持（因為他們的規模太龐大），其中含有很多屬性，會讓他們的狀態很難被管理，又符合許多協議，混合了協議的響應代碼與控制器的邏輯。

大規模的視圖控制器是很難測試的，不管是手動測試還是單元測試，因為他們有很多可能的狀態。把你的代碼分割的更少，更小更簡單通常是一件很好的事情。

缺少網絡邏輯

MVC的定義 - 蘋果使用的那個 - 規定所有對象可以被分類為一個類型，一個視圖，或者一個控制器。所有這些。所以，你應該吧網絡代碼放在哪裡呢？而代碼與API的通信又在哪裡呢？

你可以試著巧妙的把它放在模型對象裡，但是這麼做可能會變得很棘手，因為網絡調用應該是異步的過程。所以，如果一個網絡請求會超越擁有它的模型，好吧，它變復雜了。你絕對不應該把網絡代碼放進視圖裡，所以…應該留給控制器來處理。這是一個不好的想法，因為它會促使我們產生大規模的視圖控制器這個問題。

那麼，在哪裡呢？對於代碼來說，MVC的這三個組成部分沒有一個地方不適合代碼。

 

可測性差

MVC還有另外一個大問題就是，它不鼓勵開發者編寫測試用例。自從視圖控制器視圖操作邏輯與業務邏輯混合，把這些單元測試分開就成了一項艱巨的任務。都贊成忽視這個任務（單元測試）…所以就沒有測試任何東西。   “Manage”的模糊定義

 

我前面提到的那個視圖控制器來管理視圖層次的部分，視圖控制器有一個“視圖”屬性，並且可以通過IBOutLets訪問該視圖的子視圖。這樣的擴展就不太好，因為當你有很多outlets時，並且在某些時候，你可能還是使用子視圖控制器去管理你所有的子視圖會更好。     那麼在哪裡呢？他什麼時候會有益於把事物分割和細化呢？請問，業務邏輯是否會驗證用戶的輸入屬於控制器，或者屬於模型？     這裡有很多模糊的線，似乎沒有人能完全同意。當你畫這些線的時候似乎沒有問題，視圖和其相應的控制器變得如此緊密而且耦合，那你還不如把他們看作是一個組件。     嘿！現在有一個主意…

Model-View-ViewModel（MVVM）

 

在一個理想的世界，MVC可以很好的工作，然而，我們生活在一個真實的世界，事實也並非如此。現在，我們已經詳細介紹了MVC打破典型用法的方法，讓我們來看看另一種：模型 - 視圖 -視圖模型。    

MVVM來自微軟，但不要堅決反對使用它。MVVM和MVC非常相似。它讓視圖和控制器具有一定形式的緊密耦合的性質，並且還引入了一個新的組件。

在MVVM，視圖和視圖控制器正式形成連接；我們把他們作為一個組件。視圖仍然沒有對模型進行引用，但是也沒有引用控制器。相反的，他們引用視圖模型。  

視圖模型是作為用戶輸入驗證邏輯的好地方，通過視圖呈現邏輯，附加的網絡請求，和其他復雜的代碼。有一件事是，視圖本身在視圖模型中不屬於任何視圖的引用。視圖模型中的這個邏輯對於iOS和OS X中應該是同樣適用的。(換一種說法，不要在你的視圖模型中#import UIKit.h，你會被罰款的)。

由表現邏輯，比如映射一個模型值去格式化一個東西--屬於視圖模型中，視圖控制器本身會變得很大，但是並非臃腫。最好的部分是當你使用MVVM，你可以放置一小部分邏輯在你的視圖模型中，當你成為越來越適合的范例時再把它們遷移過來。

使用MVVM編寫的iOS應用程序是高度可測試的；因為視圖模型包含了所有的演示邏輯並且不引用這個視圖，它可以通過編程進行全面測試。雖然很多黑客參與測試Core Data模型，但是使用MVVM編寫的應用程序完全可以進行單元測試。

在我的經驗中，使用MVVM的結果是，代碼的總量略有增加，但在代碼的復雜性部分整體下降。這是一個權衡過後很核算的方法。

如果你再回頭看看MVVM圖解，你會發現，我用了模稜兩可的動詞“通知”和“更新”，但是沒有支出應該怎麼做。你可以用KVO，就像MVC，但是很快就會變得很難管理。在實踐中，使用ReactiveCocoa是把所有模塊粘合在一起的一個好方法。