MVC是構建iOS App的標準模式。然而，最近我已經越來越厭倦MVC的壹些缺點。在本文，我將重溫壹下MVC是什麽，詳述它的缺點，並且告訴妳壹個新的方式來架構妳的App：Model-View-ViewModel。拿出妳的流行語bingo card(賓果卡，壹種遊戲卡片-譯者註)，因為我們即將進行壹次範式轉變。
Model-View-Controller
Model-View-Controller是壹個用來組織代碼的權威範式。Apple甚至是這麽說的。在MVC下，所有的對象被歸類為壹個model，壹個view，或壹個controller。Model持有數據，View顯示與用戶交互的界面，而View Controller調解Model和View之間的交互。
在上圖中，view將用戶交互通知給controller。view controller通過更新model來反應狀態的改變。model（通常使用Key-Value-Observation）通知controller來更新他們負責的view。大多數iOS應用程序的代碼使用這種方式來組織。
模型model的對象通常非常非常的簡單。很多時候，他們就是Core Data managed objects，或者避免使用Core Data，就是其他流行的數據模型層。根據Apple的文檔，model包括數據和操作數據的業務邏輯。在實踐中，model層往往非常薄，不管怎樣，model層的業務邏輯被拖入了controller。
視圖view通常是UIKit控件（component，這裏根據習慣譯為控件）或者編碼定義的UIKit控件的集合。進入.xib或者Storyboard會發現壹個app、Button、Label都是由這些可視化的和可交互的控件組成。妳懂的。View不應該直接引用model，並且僅僅通過IBAction事件引用controller。業務邏輯很明顯不歸入view，視圖本身沒有任何業務。
還有控制器controller。Controller是app的“膠水代碼”：協調模型和視圖之間的所有交互。控制器負責管理他們所擁有的視圖的視圖層次結構，還要響應視圖的loading、appearing、disappearing等等，同時往往也會充滿我們不願暴露的model的模型邏輯以及不願暴露給視圖的業務邏輯。這引出了第壹個關於MVC的問題...
厚重的View Controller
由於大量的代碼被放進view controller，導致他們變的相當臃腫。在iOS中有的view controller裏綿延成千上萬行代碼的事並不是前所未見的。這些超重app的突出情況包括：厚重的View Controller很難維護（由於其龐大的規模）；包含幾十個屬性，使他們的狀態難以管理；遵循許多協議（protocol），導致協議的響應代碼和controller的邏輯代碼混淆在壹起。
厚重的view controller很難測試，不管是手動測試或是使用單元測試，因為有太多可能的狀態。將代碼分解成更小的多個模塊通常是件好事。
遺失的網絡邏輯
蘋果使用的MVC的定義是這麽說的：所有的對象都可以被歸類為壹個model，壹個view，或是壹個controller。就這些。那麽把網絡代碼放哪裏？和壹個API通信的代碼應該放在哪兒？
妳可能試著把它放在model對象裏，但是也會很棘手，因為網絡調用應該使用異步，這樣如果壹個網絡請求比持有它的model生命周期更長，事情將變的復雜。顯然也不應該把網絡代碼放在view裏，因此只剩下controller了。這同樣是個壞主意，因為這加劇了厚重View Controller的問題。
那麽應該放在那裏呢？顯然MVC的3大組件根本沒有適合放這些代碼的地方。
較差的可測試性
MVC的另壹個大問題是,它不鼓勵開發人員編寫單元測試。由於view controller混合了視圖處理邏輯和業務邏輯，分離這些成分的單元測試成了壹個艱巨的任務。大多數人選擇忽略這個任務，那就是不做任何測試。
定義模糊的“Manage”
之前我提到了view controller可以管理試圖的層次結構；view controller有壹個“view”屬性，並且可以通過IBOutlet訪問視圖的任何子視圖。當有很多outlet時這樣做不易於擴展，在某種意義上，最好不要使用子視圖控制器（child view controller）來幫助管理子視圖（subview）。
要點在哪？驗證用戶輸入的業務邏輯應歸入controller還是model呢？
在這裏有多個模糊的標準，似乎沒有人能完全達成壹致。貌似無論如何，view和對應的controller都緊緊的耦合在壹起，總之，還是會把它們當成壹個組件來對待。
Hey！現在有個點子...
Model-View-ViewModel
在理想的世界裏，MVC也許工作的很好。然而，我們生活在真實的世界。既然我們已經詳細說明了MVC在典型場景中的問題，那讓我們看壹看壹個可供替換的選擇：Model-View-ViewModel。
MVVM來自微軟，不過不要堅持反對它。MVVM和MVC很像。它正式規範了視圖和控制器緊耦合的性質，並引入新的組件。
在MVVM裏，view和view controller正式聯系在壹起，我們把它們視為壹個組件。視圖view仍然不能直接引用模型model，當然controller也不能。相反，他們引用視圖模型view model。
view model是壹個放置用戶輸入驗證邏輯，視圖顯示邏輯，發起網絡請求和其他各種各樣的代碼的極好的地方。有壹件事情不應歸入view model，那就是任何視圖本身的引用。view model的概念同時適用於於iOS和OS X。（換句話說，不要在view model中使用 #import UIKit.h）
由於展示邏輯（presentation logic）放在了view model中（比如model的值映射到壹個格式化的字符串），視圖控制器本身就會不再臃腫。當妳開始使用MVVM的最好方式是，可以先將壹小部分邏輯放入視圖模型，然後當妳逐漸習慣於使用這個範式的時候再遷移更多的邏輯到視圖模型中。
使用MVVM的iOS app是高度可測試的；因為view model包含了所有的展示邏輯並且不會引用view，所以它可以通過編程方式充分測試。雖然有眾多的hack技術參與到測試Core Data模型，但使用MVVM寫的app可以進行充分的單元測試。
以我的經驗，使用MVVM會輕微的增加代碼量，但總體上減少了代碼的復雜性。這是壹個劃算的交易。
妳可以使用KVO，就像MVC那樣，但這很快就會變得難以管理。事實上，使用ReactiveCocoa會是更好的方式來組織各個部分。