1.MVC For Cocoa
Cocoa的MVC模式驅使人們寫出臃腫的視圖控制器，因為它們經常被混雜到View的生命周期中，因此很難說View和ViewController是分離的。盡管仍可以將業務邏輯和數據轉換到Model，但是大多數情況下當需要為View減負的時候我們卻無能為力了，View的最大的任務就是向Controller傳遞用戶動作事件。ViewController最終會承擔一切代理和數據源的職責，還負責一些分發和取消網絡請求以及一些其他的任務，因此它的名字的由來…你懂的。

你可能會看見過很多次這樣的代碼：

var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
userCell.configureWithUser(user)

這個cell,正是由View直接來調用Model，所以事實上MVC的原則已經違背了，但是這種情況是一直發生的甚至於人們不覺得這裡有哪些不對。如果嚴格遵守MVC的話，你會把對cell的設置放在 Controller 中，不向View傳遞一個Model對象，這樣就會大大增加Controller的體積。

“Cocoa 的MVC被寫成Massive View Controller 是不無道理的。”
直到進行單元測試的時候才會發現問題越來越明顯。因為你的ViewController和View是緊密耦合的，對它們進行測試就顯得很艱難–你得有足夠的創造性來模擬View和它們的生命周期，在以這樣的方式來寫View Controller的同時，業務邏輯的代碼也逐漸被分散到View的布局代碼中去。

“View和Controller的接口並不適合單元測試。”

2.MVP (MVP 實現了Cocoa的MVC的願景)

vcC01/bV4tCpysLH6aGjwP3I56OsztLDx7/J0tTX9rv509rV+7j2QXBwt7bOp8TatcTCt9PJt/7O8aOs08nL/MC0uLrU8Na00NDQrbX3yM7O8aOs0tS8sFZpZXe1vVZpZXe1xNW5yr6ho9XiuPaz9s/WsqLH0rHY0Ou0psDttcTOyszisru99r32ysfU2k1WUMSjyr3W0KOszazKsdKytObU2tPa0tTPwryv1tC3vbC41tChozwvcD4NCjxwPjxzdHJvbmc+My5NVlZNICZuZGFzaDsg1+7QwsfSysfX7s6wtPO1xE1WKFgpz7XB0LXE0rvUsTwvc3Ryb25nPjwvcD4NCjxwPk1WVk283Lm5ysdNVihYKc+1wdDX7tDCtcTSu9Sxo6zS8rTLyMPO0sPHz6PN+8v80tG+rb+8wse1vU1WKFgpz7XB0NbQ1q7HsNLRvq2z9s/WtcTOyszioaM8YnIgLz4NCrTTwO3C27Ljw+bAtL2yTVZWTb+0xvDAtLK7tO2jrM7Sw8fS0b6tt8ezo8rsz6RWaWV3us1Nb2RlbKOs0tS8sE1lZGl0b3KjrNTaTVZWTdbQy/zKx1ZpZXcgTW9kZWyhozwvcD4NCjxwPjxpbWcgYWx0PQ=="這裡寫圖片描述" src="/uploadfile/Collfiles/20160820/201608200933571248.png" title="\" />

它和MVP模式看起來非常像:

1.MVVM將ViewController視作View 2.在View和Model之間沒有緊密的聯系

 

此外，它還有像監管版本的MVP那樣的綁定功能，但這個綁定不是在View和Model之間而是在View和ViewModel之間。
那麼問題來了，在iOS中ViewModel實際上代表什麼？它基本上就是UIKit下的每個控件以及控件的狀態。ViewModel調用會改變Model同時會將Model的改變更新到自身並且因為我們綁定了View和ViewModel，第一步就是相應的更新狀態。

綁定

我在MVP部分已經提到這點了，但是該部分我們仍會繼續討論。
如果我們自己不想自己實現，那麼我們有兩種選擇:

基於KVO的綁定庫如 RZDataBinding 和 SwiftBond 完全的函數響應式編程，比如像ReactiveCocoa、RxSwift或者 PromiseKit
事實上，尤其是最近，你聽到MVVM就會想到ReactiveCoca，反之亦然。盡管通過簡單的綁定來使用MVVM是可實現的，但是ReactiveCocoa卻能更好的發揮MVVM的特點。
但是關於這個框架有一個不得不說的事實：強大的能力來自於巨大的責任。當你開始使用Reactive的時候有很大的可能就會把事情搞砸。換句話來說就是，如果發現了一些錯誤，調試出這個bug可能會花費大量的時間.

 

 

讓我們再來看看關於三個特性的評估：

    *任務均攤* -- 在例子中並不是很清晰，但是事實上，MVVM的View要比MVP中的View承擔的責任多。因為前者通過ViewModel的設置綁定來更新狀態，而後者只監聽Presenter的事件但並不會對自己有什麼更新。
    *可測試性* -- ViewModel不知道關於View的任何事情，這允許我們可以輕易的測試ViewModel。同時View也可以被測試，但是由於屬於UIKit的范疇，對他們的測試通常會被忽略。
    *易用性* -- 在我們例子中的代碼量和MVP的差不多，但是在實際開發中，我們必須把View中的事件指向Presenter並且手動的來更新View，如果使用綁定的話，MVVM代碼量將會小的多。

“MVVM很誘人，因為它集合了上述方法的優點，並且由於在View層的綁定，它並不需要其他附加的代碼來更新View，盡管這樣，可測試性依然很強。”

4.VIPER–把LEGO建築經驗遷移到iOS app的設計

VIPER是我們最後要介紹的，由於不是來自於MV(X)系列，它具備一定的趣味性。
迄今為止，劃分責任的粒度是很好的選擇。VIPER在責任劃分層面進行了迭代，VIPER分為五個層次:


VIPER

交互器 – 包括關於數據和網絡請求的業務邏輯，例如創建一個實體（數據），或者從服務器中獲取一些數據。為了實現這些功能，需要使用服務、管理器，但是他們並不被認為是VIPER架構內的模塊，而是外部依賴。

    展示器 -- 包含UI層面的業務邏輯以及在交互器層面的方法調用。
    實體 -- 普通的數據對象，不屬於數據訪問層次，因為數據訪問屬於交互器的職責。
    路由器 -- 用來連接VIPER的各個模塊。

基本上，VIPER模塊可以是一個屏幕或者用戶使用應用的整個過程–想想認證過程，可以由一屏完成或者需要幾步才能完成，你的模塊期望是多大的，這取決於你。

    Model 邏輯通過把實體作為最小的數據結構轉換到交互器中。
    Controller/Presenter/ViewModel的UI展示方面的職責移到了Presenter中，但是並沒有數據轉換相關的操作。
    VIPER是第一個通過路由器實現明確的地址導航模式。

“找到一個適合的方法來實現路由對於iOS應用是一個挑戰，MV(X)系列避開了這個問題。”