MVC
模型（Model）－ 視圖（View）－ 控制器（Controller）
目的：將Model與View的實現代碼分離
Apple的MVC中：
- Model：存儲數據，不負責如何展示數據，Model層最好就是負責純粹的數據結構，響應的數據操作可以放到擴展中。
- View：對Model中的數據進行展示，與用戶交互
- Controller：
- Model與View之間的連接器，控制程序的流程，處理事件并做出響應
- 為應用程序執行設置和協調任務，管理其他對象的聲明周期
傳統的MVC
iOS 理想MVC示意圖
- Model與View只能通過Controller通信
- Cotroller直接讀寫調用Model，Model通過KVO或Notification與Controller間接通信
- Cotroller與View直接對話，通過outlet操作View，View通過delegate向Controller提交事件
- Controller是View的直接數據源（數據可能是Controller從Model中取得并加工過）
蘋果推薦的MVC事實
- View綁定在ViewController上
- 業務邏輯和展示邏輯全部放在ViewController中
- View與Model直接進行交互，耦合性嚴重
MVC的不足
- 愈發臃腫的Controller
- 太過輕量的Model
- 遺失的網絡邏輯
- 較差的可測試性
MVP
MVP屬于Presentation層的設計模式
目的：顯示邏輯與業務邏輯分離，提高自動化單元測試
- Model：模塊的業務邏輯和數據的提供者
- View：數據的可視化呈現
- Presenter：從Model中取出數據，并格式化展示在View中
通常View會實例化Presenter對象，并提供對自身的引用
Model、Presenter、View之間的通信：
- Model和View使用Observer模式溝通
- Presenter與View使用Mediator模式溝通
- Presenter使用Command模式控制Model
MVP中，用戶請求首先到達View層，在由View層調用Presenter層，Presenter從Model去數據，處理后，調用View 層更新
MVP變體較多，常用的變體為Passive View（被動 視圖），其特點：
- View、Model不直接交互，View通過Presenter與Model打交道
- Presenter接受View的UI請求，處理簡單的UI邏輯（即View調用Presenter接口）
- Presenter調用Model處理業務邏輯，并調用View展示結果（即Presenter調用View接口）
在Passive View中，主動的是Presenter：
- Presenter是MVP體系的控制中心，并非單純的處理View的請求
- Presenter是View與Model之間的協調者，根據交互邏輯給View和Model安排工作
- View僅作為交互請求的匯報者，響應的交互邏輯由Presenter處理
- 綁定在View上的數據，應由Presenter主動推送，而不是由View主動拉取
- View盡可能不維護數據的狀態，僅單純的實現獨立的UI操作
缺點：MVP中Presenter與View互相持有，導致Presenter服用性差
iOS的MVP中，View的角色由ViewController扮演，而不是UIView
誤區
- 把Presenter視為View調用Model的中介，Presenter變為Proxy
- UI處理邏輯大部分寫在View中，Presenter僅影響View對Model的調用
MVVM
MVVM：由MVP模式與WPF技術結合演變的一種使用數據綁定的基礎架構
MVVM中View與ViewModel沒有MVP的界面接口，而是采用數據綁定的形式讓數據更新的事件不需要開發人員手動去編寫特殊用例
Model：
View：
ViewModel：一個值轉換器，負責將Model轉換成易于管理和展示的數據對象。
- ViewModel與View之間可以使用Mediator模式
- ViewModel與MVC的C和MVP的P不同，具有綁定器
viewModel持有model
對于可變 Model，我們還需要使用一些綁定機制，這樣 View Model 就能在背后的 Model 改變時更新自身的屬性。此外，一旦 View Model 上的 Model 發生改變，那 View 的屬性也需要更新。Model 的改變應該級聯向下通過 View Model 進入 View。
MVVM的兩個原則：
- View持有ViewModel的引用
- ViewModel持有Model的引用
iOS中目前只能通過RAC來完成雙向綁定
MVVM優點：
- 兼容當下的MVC
- 增加可測試性
- 配合綁定機制更好，簡化了業務與界面的依賴方式，還優化了數據頻繁更新的解決方案
沒有使用雙向綁定的MVVM，與MVP區別不大，在數據驅動界面展示的情況下，必須先修改數據源，然后在刷新界面，如果直接修改界面展示，則要注意將最新的界面狀態刷回數據源，否則會出現問題，一些情況下，可能只修改了界面的一個屬性，但是卻要把整個數據源刷一遍就有些就會耗時，顯得很多余，如果使用雙向綁定，則可以解決這些問題。
為什么MVP、MVVM中P/VM要使用中介者模式與V通信
- MVP中，P和V交互需要將接口暴露給對方，在業務邏輯不復雜，或者V層的復用性不大的情況下，P和V互相持有是最為簡便的做法
- MVP中V會持有P、MVVM中V會持有VM，導致V與P／VM綁定在一起，如果想要在其他地方復用V但業務邏輯不太一樣，相應的業務邏輯就增加在之前的P或者VM里面了，導致P和VM邏輯變得復雜和臃腫
- 通過中介者模式，將V與P/VM進行解耦，相當于給V增加了一個Controller，MVP/MVVM編程了MVCP/MVCVM模式，此時的View層僅僅負責展示邏輯，數據的綁定以及和上層的交互，交給了中介者C層進行了處理
iOS 架構模式--解密MVC，MVP，MVVM以及VIPER架構
雜談: MVC/MVP/MVVM
淺談MVP架構及開發模式
界面之下：還原真實的 MVC、MVP、MVVM 模式
MVVM 介紹
iOS開發之MVVM設計模式
iOS-ReactiveCocoa(RAC)的高級使用之視圖與模型的雙向綁定
MVVM與Controller瘦身實踐
