從字面意思來理解叨吮，MVP 即 Modal View Presenter（模型 視圖 協(xié)調器）彬祖，MVP 實現(xiàn)了 Cocoa 的 MVC 的愿景硬鞍。MVP 的協(xié)調器 Presenter 并沒有對 ViewController 的生命周期做任何改變，因此 View 可以很容易的被模擬出來睬澡。在 Presenter 中根本沒有和布局有關的代碼雀哨，但是它卻負責更新 View 的數(shù)據和狀態(tài)磕谅。MVC 和 MVP 的區(qū)別就是，在 MVP 中 M 和 V 沒有直接通信雾棺。
MVP 是第一個如何協(xié)調整合三個實際上分離的層次的架構模式膊夹，既然我們不希望 View 涉及到 Model，那么在顯示的 View Controller（其實就是 View）中處理這種協(xié)調的邏輯就是不正確的捌浩，因此我們需要在其他地方來做這些事情放刨。例如，我們可以做基于整個 App 范圍內的路由服務尸饺，由它來負責執(zhí)行協(xié)調任務进统，以及 View 到 View 的展示。這個出現(xiàn)并且必須處理的問題不僅僅是在 MVP 模式中浪听，同時也存在于以下集中方案中螟碎。
1）MVP模式下的三個特性的分析：
任務均攤 -- 我們將最主要的任務劃分到 Presenter 和 Model，而 View 的功能較少迹栓；
可測試性 -- 非常好掉分，由于一個功能簡單的 View 層，所以測試大多數(shù)業(yè)務邏輯也變得簡單克伊；
易用性 -- 代碼量比 MVC 模式的大酥郭，但同時 MVP 的概念卻非常清晰。
2）iOS MVP 示意圖：
就 MVP 而言愿吹，UIViewController 的子類實際上就是 Views 并不是 Presenters不从。這點區(qū)別使得這種模式的可測試性得到了極大的提高，付出的代價是開發(fā)速度的一些降低洗搂，因為必須要做一些手動的數(shù)據和事件綁定消返。
還有一些其他形態(tài)的 MVP -- 監(jiān)控控制器的 MVP。這個變體包含了 View 和 Model 之間的直接綁定耘拇，但是 Presenter 仍然來管理來自 View 的動作事件撵颊，同時也能勝任對 View 的更新。
3）規(guī)范的 MVP 設計模式：
1惫叛、View 層比較簡單明倡勇，就是 View 的一些封裝、重用嘉涌。在一款精心設計過的 App 里面妻熊，應該有很多 View 是可以封裝重用的。比如一些自己的 TableViewCell仑最，自己設計的 Button扔役，一些 View（包含一些子 View，UI 精心設計過警医，在項目里多處出現(xiàn)的）等等亿胸。
2、Model 層應該不僅僅是創(chuàng)建一個數(shù)據對象预皇，還應該包含網絡請求侈玄，以及數(shù)據 SQLite 的 CRUD 操作（比如 iOS 平臺，一般以 FMDB 框架直接操作 sql吟温，或者用 CoreData) 序仙。一般可以將數(shù)據對象是否需要緩存設計成一個字段 isCache，或者針對整個項目設計一個開存儲關鲁豪，決定整個項目是否需要數(shù)據緩存潘悼。我們常見的新聞類 App，在離線的時候看到的數(shù)據爬橡，都是做了緩存處理的挥等。比如一些金融類的 App，實時性比較高堤尾，是不做緩存的肝劲。
3、Presenter 層并不涉及數(shù)據對象的網絡請求和 SQLite 操作郭宝，只是 Model 層和 View 層的一個橋梁辞槐。Presenter 層就不至于太臃腫，容易看懂粘室。一些大的 App榄檬，或因為上線時間比較久了，經歷過眾多程序員的修補衔统，或因前期并未做好架構鹿榜，以至于打開一個類海雪，幾千行的代碼，看著自己都暈舱殿。
