在這篇文章里，我們爭取用最精簡的語言，解釋清楚這幾種設計模式到底給我帶來了什么便利。
以看圖說話的方式逐一解釋，最后總結
MVC
這是我們最早接觸，也最熟悉的設計模式了
但要記住 Controller 不是我們通常理解的 ViewController ！Controller 你可以認為是 Helper 方法。他不掌管 View 的生命周期。也就是說和 UIKit 無關！ViewController 你可以把他理解為 Scene 或 裝配中心。
感謝有人做了一個精辟的總結。看圖理解吧:
這才是真正的 MVC 使用姿勢。
MVP
從對比可以看到 MVC 的 Controller 變成了 Presenter ?, UIView 或 UIViewController 為 View 層。View 持有 Presenter，Presenter 持有 Model。View 與 Model 完全隔離。
當事件發生，交由 Presenter 進行業務邏輯處理，Presenter 從 Model 拿數據，拿到數據后然后將數據返回給Presenter，Presenter 再返回給 View 。可以理解 Presenter 是一個中間人。
同樣 Presenter 應完全不依賴 UIKit 。如果需要與 View 交互，可以采用 Protocol 協議進行約定，調用。保證邏輯清楚，可測試。
最簡樣列代碼：
注意中文標注的地方。
另外還有一個 Supervising Presenter MVP 的升級版本，將 View 與 Model 進行綁定。View 會受到 Model 的變更影響，同時 Presenter 依舊可以控制 View 狀態。這種模糊的職責關系，還是少用為好。
MVVM
和 MVP 一樣，View Model 承擔了類似 Presenter 中間層的角色。區別在于"數據與用戶行為"的綁定是在 View 與 View Model 層上發生的。這個時候不影響這個設計架構中 View Model 應該承擔的角色屬性：更新 View 狀態。
關于綁定我們可以用 KVO 模式及函數式編程來實現我們的所需。如果你想更高效的完成這個動作，可以參考現有的解決方案:
? 1.? KVO : RZDataBinding or the SwiftBond
? 2.? Functional programming:? ReactiveCocoa, RxSwift or PromiseKit
不過，對于 ReactiveCocoa 我只能說慎用，設計起來會非常麻煩。
這里，我們還列舉最簡單的例子，沒有用到 KVO 或 RX 之類的設計，使用最為傳統的 Protocol 來實現彼此的交互過程
我們可以看重點中文標注的地方，這里通過協議里的定義，第一步 View 層發起數據請求 showGreeting 交由 ViewModel 進行數據處理，處理完成后，因 greeting 發生變化，觸發 greetingDidChange 事件發生。
在這個實例里 ViewController 有設定 greetingDidChange 回調，所以實現了類似了上面所說的數據與行為綁定。
VIPER
從結構上來看，在 Presenter 中間多了一層 Interactor ，它主要起到了數據維護訪問的職責。你可以封裝更多的 Service 或 Managers 做為依賴調用。
對于頁面間的跳轉，這里增加了 Router 層，專門用于跳轉邏輯，實際上現在不少架構已經加了各自的 Router 邏輯。這一點可能是從 Rails 框架繼承而來。
下面的例子不包含 Router 層
從以上最簡的示例代碼來看，View 層 (ViewController) 同樣還是通過 ?Presenter 層 (GreetingViewEventHandler) 觸發事件邏輯，只不過 Presenter 拿數據是從 Iteractor 層（GreetingProvider）去拿。層與層之間還是通過協議通導，不依賴實體。
從這個架構來看，它的耦合性是最小的，不過也帶了設計上的復雜性。所以使用時，要因地制宜。
總結
最后附上一位專家 Bohdan Orlov 的總結，它們的橫向對比圖，尋找自己最適合的模式使用。
耦合度 (Distribution)
可測性 (Testability)
易用性 (Ease of use)
PS：這里也提到了 Redux 模式，想了解 Redux 相關的內容話，看這個鏈接吧。研究不深，大致是和 FP (函數式編程) 與 State 流相關。
總而言之
1. 沒有殺手锏
? ? no Sliver Bullet
2. 分層治理
? ? 分久必合，合久并分，看具體業務場景
4. 低耦合，高內聚
? ? 基本要素
5. 遵從流行的框架與概念，有利于團隊間的溝通成本
? ? 如果一定要發明，請多推廣你的概念
6. 從簡到繁，再化繁為簡
? ? 前一個繁是業務的屬性，后一個繁是框架本身
