Android開發MVP模式解析

http://www.cnblogs.com/bravestarrhu/archive/2012/05/02/2479461.html

在開發Android應用時，相信不少同窗遇到和我同樣的狀況，雖然項目剛開始構架時自認爲MVC層級分的特別明確，但最終每每是一個Activity有好幾百行代碼，並且邏輯和UI顯示徹底混雜在一塊兒，致使後續項目的維護成本巨大。一個偶然的機會看到有種MVP模式（Mode-View-Presenter）能夠比MVC更好的解耦和，而後好奇的研究了下這個模式並嘗試在如今項目中進行推廣。下面就把本身目前學習到知識總結出來。

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

（一）Android開發MVP模式解析

（二）Android開發MVP模式實踐

1、MVP簡介

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

2、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交互。

 

3、MVP VS MVC

在把本來MVC模式的代碼修改成MVP模式後，總結這兩個模式在實際使用過程當中的不一樣點基本上總結爲兩點：

 

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

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

 

4、總結

MVP將會爲你的代碼帶來以下好處：

 

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

參考資料：

Android上的MVP模式

MVC or MVP Pattern - Whats the difference?

Architecting Android...The Clean way?