iOS - MVP 架構模式

一、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 設計模式：

  • 一、View 層比較簡單明，就是 View 的一些封裝、重用。在一款精心設計過的 App 裏面，應該有不少 View 是能夠封裝重用的。好比一些本身的 TableViewCell，本身設計的 Button，一些 View（包含一些子 View，UI 精心設計過，在項目裏多處出現的）等等。

  • 二、Model 層應該不單單是建立一個數據對象，還應該包含網絡請求，以及數據 SQLite 的 CRUD 操做（好比 iOS 平臺，通常以 FMDB 框架直接操做 sql，或者用 CoreData) 。通常能夠將數據對象是否須要緩存設計成一個字段 isCache，或者針對整個項目設計一個開存儲關，決定整個項目是否須要數據緩存。咱們常見的新聞類 App，在離線的時候看到的數據，都是作了緩存處理的。好比一些金融類的 App，實時性比較高，是不作緩存的。

  • 三、Presenter 層並不涉及數據對象的網絡請求和 SQLite 操做，只是 Model 層和 View 層的一個橋樑。Presenter 層就不至於太臃腫，容易看懂。一些大的 App，或由於上線時間比較久了，經歷過衆多程序員的修補，或因前期並未作好架構，以致於打開一個類，幾千行的代碼，看着本身都暈。