1、MVP
-
從字面意思來理解，MVP 即 Modal View Presenter（模型 視圖 協調器），MVP 實現了 Cocoa 的 MVC 的願景。MVP 的協調器 Presenter 並沒有對 ViewController 的生命周期做任何改變，因此 View 可以很容易的被模擬出來。在 Presenter 中根本沒有和布局有關的代碼，但是它卻負責更新 View 的數據和狀態。MVC 和 MVP 的區別就是，在 MVP 中 M 和 V 沒有直接通信。
-
MVP 是第一個如何協調整合三個實際上分離的層次的架構模式，既然我們不希望 View 涉及到 Model，那么在顯示的 View Controller（其實就是 View）中處理這種協調的邏輯就是不正確的，因此我們需要在其他地方來做這些事情。例如，我們可以做基於整個 App 范圍內的路由服務，由它來負責執行協調任務，以及 View 到 View 的展示。這個出現並且必須處理的問題不僅僅是在 MVP 模式中，同時也存在於以下集中方案中。
-
1）MVP模式下的三個特性的分析：
- 任務均攤 -- 我們將最主要的任務划分到 Presenter 和 Model，而 View 的功能較少；
- 可測試性 -- 非常好，由於一個功能簡單的 View 層，所以測試大多數業務邏輯也變得簡單；
- 易用性 -- 代碼量比 MVC 模式的大，但同時 MVP 的概念卻非常清晰。
-
2）iOS MVP 示意圖：
-
就 MVP 而言，UIViewController 的子類實際上就是 Views 並不是 Presenters。這點區別使得這種模式的可測試性得到了極大的提高，付出的代價是開發速度的一些降低，因為必須要做一些手動的數據和事件綁定。
-
還有一些其他形態的 MVP -- 監控控制器的 MVP。這個變體包含了 View 和 Model 之間的直接綁定，但是 Presenter 仍然來管理來自 View 的動作事件，同時也能勝任對 View 的更新。
-
-
3）規范的 MVP 設計模式：
-
1、View 層比較簡單明，就是 View 的一些封裝、重用。在一款精心設計過的 App 里面，應該有很多 View 是可以封裝重用的。比如一些自己的 TableViewCell，自己設計的 Button，一些 View（包含一些子 View，UI 精心設計過，在項目里多處出現的）等等。
-
2、Model 層應該不僅僅是創建一個數據對象，還應該包含網絡請求，以及數據 SQLite 的 CRUD 操作（比如 iOS 平台，一般以 FMDB 框架直接操作 sql，或者用 CoreData) 。一般可以將數據對象是否需要緩存設計成一個字段 isCache，或者針對整個項目設計一個開存儲關，決定整個項目是否需要數據緩存。我們常見的新聞類 App，在離線的時候看到的數據，都是做了緩存處理的。比如一些金融類的 App，實時性比較高，是不做緩存的。
-
3、Presenter 層並不涉及數據對象的網絡請求和 SQLite 操作，只是 Model 層和 View 層的一個橋梁。Presenter 層就不至於太臃腫，容易看懂。一些大的 App，或因為上線時間比較久了，經歷過眾多程序員的修補，或因前期並未做好架構，以至於打開一個類，幾千行的代碼，看着自己都暈。
-