從字面意思來了解，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，或因為上線時間比較久了，經曆過衆多程式員的修補，或因前期并未做好架構，以至于打開一個類，幾千行的代碼，看着自己都暈。