譯至:
Essential Guide For Designing Your Android App Architecture: MVP: Part 1

安卓架構(gòu)并沒有要求開發(fā)者用指定的方法去設(shè)計應(yīng)用寂呛。也正是這樣誊涯，才使得我們在開發(fā)的時候冒冬，更自由但也更容易犯錯誤。

為什么我會想到這個呢昆汹，當系統(tǒng)提供的activity和在整個實現(xiàn)過程中，實際上我只是用到很少的activity

在安卓平臺上開發(fā)的這些年恶阴，我意識到淌山，在當時寫下的代碼解決一個問題或者實現(xiàn)一種功能拯勉，并不能滿足后來的需要竟趾。你的應(yīng)用將經(jīng)歷很多的變化周期和功能的添加或移除憔购。如果沒有用分塊的概念來設(shè)計，經(jīng)過一段時間的需求變更岔帽，你的應(yīng)用代碼會很混亂且不好維護玫鸟。經(jīng)過之前應(yīng)用經(jīng)驗，我寫了一個簡單的代碼來構(gòu)建之后我所有的應(yīng)用設(shè)計框架犀勒，這就是為什么我提出這個指導.

MVP是我目前所見到的最好體現(xiàn)這種原則的框架

什么是MVP和為什么我們應(yīng)該探究它?

在過去屎飘，我們中的大多數(shù)，以activity為核心創(chuàng)建一個應(yīng)用然后就有能力去決定開始做什么和怎樣獲取數(shù)據(jù)贾费。經(jīng)過一段時間钦购，activity中的代碼不斷地增加和成為一種不可重復利用的組件。我們開始從復雜的activity中铸本，分離出相關(guān)聯(lián)的代碼打包成為組件肮雨，然后提供api給acitivity調(diào)用遵堵。我們在不斷地盡可能地將相關(guān)的代碼分離出來的過程中感到很自豪箱玷。之后，我們就會開始發(fā)現(xiàn)代碼中存在很多分離出來的組件陌宿，導致很難去找到它們之間的依賴和用法锡足。而且我們開始引入易測試性的概念，才發(fā)現(xiàn)壳坪，如果我們已經(jīng)寫了測試舶得，不分出來才是更安全的。我們感覺用上面的方式寫出來的代碼會很混亂并且還和安卓api緊緊地耦合爽蝴，這樣阻礙了我們做jvm測試也制約了簡單設(shè)計測試用例沐批。這種就是以Activity和Fragment作為控制器（Controller）的經(jīng)典MVC模式。

所以蝎亚，我們將闡述一些原則九孩，根據(jù)這些原則小心的實現(xiàn)，我們將會解決上面提到的大部分問題发框。這些原則我們稱做MVP（Model-View-Presenter）設(shè)計模式

什么是MVP設(shè)計模式

如果參照MVP模式進行設(shè)計躺彬，代碼之間的關(guān)聯(lián)減弱了，使得代碼的可重用性和可測試性都得到了加強梅惯。這種架構(gòu)以組件在應(yīng)用中所擔負的任務(wù)來進行分割宪拥，這也稱作分離概念。

MVP將應(yīng)用分成三種基本的組件：

1.Model：它的職責是處理應(yīng)用數(shù)據(jù)的部分

2.View：它的職責是在屏幕上布局顯示指定數(shù)據(jù)的視圖

3.Presenter：它是一個連接Model和View的橋梁铣减。也是扮演指揮view的角色她君。

根據(jù)以上提到的組件，MVP可以列出以下一些基本的規(guī)則：

1.Presenter控制View來畫UI葫哗，View是應(yīng)用中被控制的部分犁河。

2.View將委托用戶所有的交互行為給Presenter處理

3.View從不直接從Model獲取數(shù)據(jù)

4.Presenter是負責委派View的請求給Model和根據(jù)特定的事件要求View做出相應(yīng)的動作

5.Model的職責是從服務(wù)器鳖枕、數(shù)據(jù)庫、文件中抓取數(shù)據(jù)

以上提到的原則可以用許多的方法來實現(xiàn)桨螺，每個開發(fā)者都會有自己的實現(xiàn)宾符。但并不會的大的出入

根據(jù)MVP模式，我先寫下序文

1.Acitivity灭翔、Fragment和自定義View在應(yīng)用中扮演View的部分.

2.每一個View都有一個它對應(yīng)的Presenter.

3.View通過一個接口（Interface）和它對應(yīng)Presenter連接魏烫。反之亦然.

4.Model被分成幾個部分：ApiHelper, PreferenceHelper, DatabaseHelper, 和FileHelper.這些所有的數(shù)據(jù)渠道會在數(shù)據(jù)管理（DataManager）中實現(xiàn)，也就是數(shù)據(jù)管理將所有的Model進行統(tǒng)一管理.

5.Presenter通過接口調(diào)用DataManager的實現(xiàn).

6.DataManager（數(shù)據(jù)管理）只有被調(diào)用的時候才進行服務(wù).

7.Presenter沒有使用任何的安卓API.

很顯然肝箱，以上信息可以在各種博客中或者從安卓官方對MVP的介紹中找到哄褒，那這篇文章的核心是什么呢？

核心：將MVP架構(gòu)在應(yīng)用中實現(xiàn)起來

通過分析一個簡單的Activity例子：由于應(yīng)用中有很多的組件煌张，當我們都嘗試著綁定到Activity中的時候呐赡，這些組件使得我們很混亂。從這個例子看似MVP的出現(xiàn)很簡單骏融。

首先链嘀，讓我們描述這個架構(gòu)藍圖

不管你從事什么軟件工程，架構(gòu)都是一件首要考慮的事情档玻。一個小心地精心設(shè)計的框架不但提供一個很好的擴展性而且在將來還能減少大量的重復工作』巢矗現(xiàn)在很多項目都是一個團隊來開發(fā)，因此误趴，項目代碼的可讀性和模塊性在架構(gòu)設(shè)計中應(yīng)該被視為至關(guān)重要的要素霹琼。我們也有大量的依賴第三方一些庫和不斷得更換方案由于使用的場景、bugs和支持凉当。所以我們的架構(gòu)應(yīng)該設(shè)計成即插即用的設(shè)計枣申。接口（Interface）在類中的運用就是這個目的。

上面畫出來的安卓架構(gòu)藍圖包含所有的特性和是基于MVP藍圖看杭。

你看接下來的內(nèi)容可能會覺得不是那么清楚忠藤，但只要你看過這篇文章對應(yīng)下一部分給出的例子，這些概念你將會很清楚了

讓我們來理解概略架構(gòu)中每一部分

• View：這是應(yīng)用的一部分泊窘，主要用來渲染UI和接受來至用戶的交互熄驼。主要由Activity，F(xiàn)ragment和CustomView（自定義view）構(gòu)成

• MvpView : 由View來實現(xiàn)的一個接口烘豹，這個接口包含的方法都是暴露給它對應(yīng)的Presenter使用的瓜贾。

• Presenter：它的數(shù)量主要取決于View的數(shù)量并且它是一個不連接安卓API的純java類。它從對應(yīng)的View中接收用戶的交互信息携悯，然后做一些業(yè)務(wù)邏輯判斷祭芦，最后引導View運行一些指定的行為。它也可以通過數(shù)據(jù)管理（DataManager）獲取業(yè)務(wù)邏輯需要的任何數(shù)據(jù)憔鬼。

• MvpPresenter：由Presenter來實現(xiàn)的一個接口。它包含的方法主要是給它對應(yīng)的View調(diào)用的。

• AppDbHelper:應(yīng)用中的一部分宇姚，主要是數(shù)據(jù)庫管理和所有處理與數(shù)據(jù)庫相關(guān)的數(shù)據(jù)。

• DbHelper：由AppDbHelper實現(xiàn)的一個接口和包含暴露給應(yīng)用組件調(diào)用的方法仰禀。這層可以解耦任何指定實現(xiàn)DbHelper，因此使得AppDbHelper成為即插即用的模塊蚕愤。

• AppPreferenceHelper：這個就像AppDbHelper一樣答恶，只不過它的主要任務(wù)是從安卓share preference讀寫數(shù)據(jù)。

• PreferenceHelper：和DbHelper一樣的接口萍诱，只不過由AppPreferenceHelper來實現(xiàn)悬嗓。

• AppApiHelper：主要管理網(wǎng)絡(luò)相關(guān)的API調(diào)用和數(shù)據(jù)處理。

• ApiHelper：和DbHelper 一樣的接口裕坊，只不過由AppApiHelper來實現(xiàn)包竹。

• DataManager：由AppDataManager來實現(xiàn)的一個接口。它包含并暴露所有數(shù)據(jù)處理相關(guān)的操作方法籍凝。理想上周瞎，它所有實現(xiàn)委托給提供服務(wù)的所有Helper 類。對于這個DataManager接口静浴，它繼承了DbHelper, PreferenceHelper 和ApiHelper 接口.

• AppDataManager：在應(yīng)用中堰氓，它是一個聯(lián)系任何數(shù)據(jù)相關(guān)的操作挤渐。DbHelper, PreferenceHelper 和 ApiHelper 只為DataManager效勞苹享。它委托所有的實現(xiàn)給指定的任何的Helper。

現(xiàn)在我們熟悉了所有的組件和它們在一個應(yīng)用中扮演的角色浴麻。我們現(xiàn)在將在這些各種各樣組件中制定交流的模式得问。

• 應(yīng)用（Application ）類實例化AppDbHelper （賦值給DbHelper 變量），AppPreferenceHelper （賦值給PreferenceHelper 變量）软免，AppApiHelper （賦值給ApiHelper 變量）和最后將DbHelper宫纬、PreferenceHelper 和PreferenceHelper 引用傳給AppDataManager（賦值給DataManager 變量） 進行實例化。

• View 組件實例化它對應(yīng)的Presenter膏萧，并傳給MvpPresenter引用漓骚。

• Presenter接收它的View組件和并通過MvpView引用它，Presenter也接收DataManager榛泛。

• DataManager 作為一個單例存在蝌蹂。

這就是應(yīng)用去實現(xiàn)MVP模式的一個基本參考。

就像一個外科醫(yī)生談?wù)撏饪剖中g(shù)過程一樣曹锨，談?wù)摬]有什么用處孤个，只有他執(zhí)行和實踐，才能看到效果沛简。只有我們真正的行動起來齐鲤，我們才能理解和實現(xiàn)這個想法

下一部分斥废，我們將探究真正實現(xiàn)app的例子和希望能更好的理解和掌握相關(guān)的概念。
[第二部分鏈接]（https://blog.mindorks.com/essential-guide-for-designing-your-android-app-architecture-mvp-part-2-b2ac6f3f9637#.i825tgjrg）