Android開發MVP模式解析

在開發Android應用時，相信很多同學遇到和我一樣的情況，雖然項目剛開始構架時自認為MVC層級分的特別明確，但最終往往是一個Activity有好幾百行代碼，而且邏輯和UI顯示完全混雜在一起，導致后續項目的維護成本巨大。一個偶然的機會看到有種MVP模式（Mode-View-Presenter）可以比MVC更好的解耦和，然后好奇的研究了下這個模式并嘗試在現在項目中進行推廣。下面就把自己目前學習到知識總結出來。

MVP模式將分為兩篇博客進行總結：

（一）Android開發MVP模式解析

（二）Android開發MVP模式實踐

一、MVP簡介

我理解的MVP是由MVC優化衍生出來的一種模式，MVP將MVC中的Controller層進行了優化而生成了Presenter。Presenter單詞翻譯為“提出者；任命者；主持人”，Presenter層和MVC的Controller一樣，負責核心邏輯，但不一樣的是Presenter通過接口協議進行數據傳遞，并阻斷了View和Model的直接聯系，從而使View和Model更加專注于自身業務邏輯。

二、MVP結構

View

View通常來說就是有Activity、Fragment實現的，View會包含一個或多個Presenter的引用來滿足視圖的業務邏輯。View和Presenter的交互是雙向的，即View層可以調用Presenter的邏輯方法，Presenter也可以控制View的顯示。

Presenter

Presenter作為Model和View的橋梁，負責從Model拿到數據進行處理并返回給View。但Presenter和其他兩層的溝通是通過接口協議進行的，所以每個Presenter中通常會包涵一個或多個接口協議。

Model

和MVC一樣，作為數據倉庫只負責對APP數據進行處理。

Android開發MVP模式實踐中的示例將APP分為以下四層。

 

• • Entities:APP中的業務類。
  • Use Cases:負責從將Entities中的數據進行處理和包裝。
  • Presenters:從Use Cases獲取處理好的數據，然后根據需求邏輯為UI提供合適的數據。
  • UI:從Presenters獲取處理好的最終數據，和用戶進行直接交互。

這四層設計的原則是代碼調用只能從外圓向內圓擴展，內圓不能干預也不需關心外圓的功能邏輯，這符合MVP的思想，Use Cases和Presenters將Entities和UI間隔分離，從而使Entities和UI只需關心自身邏輯，數據處理完全交給其他兩層。

這里，有些同學可能會有疑問，說好的Presenters為什么會有Use Cases出來攪局？其實這也是我選擇這個工程當做示例的目的，看了好多MVP文章，都在講Presenter如何通過接口協議和其他兩層進行交互，但大都忽略了Presenter層自身的構架，因為僅僅套用MVP模式，雖然在一定程度上降低View的耦合度，但因為Presenter既要處理數據，又要結合需求控制UI交互，所以很可能出現Presenter邏輯的冗余。后文的示例工程在Presenter和Model之間包裝了Use Cases，將數據邏輯處理交給UseCases從而讓Presenter更專心于UI交互。

 

三、MVP VS MVC

在把原本MVC模式的代碼修改為MVP模式后，總結這兩個模式在實際使用過程中的不同點基本上總結為兩點：

 

• • 各個層之間通過接口協議進行溝通；
  • View和Model不再進行直接交互；

詳細說明請參考 MVC or MVP Pattern - Whats the difference?

 

四、總結

MVP將會為你的代碼帶來如下好處：

 

• View和Model之間的耦合度降低，使其更關注自身業務邏輯；
• 便于單元測試；
• 代碼復用率提高；
• 代碼框架更適用于快速迭代開發；

參考資料：

Android上的MVP模式

MVC or MVP Pattern - Whats the difference?

Architecting Android...The Clean way?

 

來自： http://blog.csdn.net/guxiao1201/article/details/40147209