基本的引导：用MVP构建你的Android应用架构part1

转载请标明出处 http://blog.csdn.net/wzhwcp/article/details/61939060 本文出自：【wzhwcp的博客】
本文译至:
Essential Guide For Designing Your Android App Architecture: MVP: Part 1

安卓架构并没有要求开发者用指定的方法去设计应用。也正是这样，才使得我们在开发的时候，更自由但也更容易犯错误。

为什么我会想到这个呢，当系统提供的activity和在整个实现过程中，实际上我只是用到很少的activity

在安卓平台上开发的这些年，我意识到，在当时写下的代码解决一个问题或者实现一种功能，并不能满足后来的需要。你的应用将经历很多的变化周期和功能的添加或移除。如果没有用分块的概念来设计，经过一段时间的需求变更，你的应用代码会很混乱且不好维护。经过之前应用经验，我写了一个简单的代码来构建之后我所有的应用设计框架，这就是为什么我提出这个指导.

MVP是我目前所见到的最好体现这种原则的框架

什么是MVP和为什么我们应该探究它?

在过去，我们中的大多数，以activity为核心创建一个应用然后就有能力去决定开始做什么和怎样获取数据。经过一段时间，activity中的代码不断地增加和成为一种不可重复利用的组件。我们开始从复杂的activity中，分离出相关联的代码打包成为组件，然后提供api给acitivity调用。我们在不断地尽可能地将相关的代码分离出来的过程中感到很自豪。之后，我们就会开始发现代码中存在很多分离出来的组件，导致很难去找到它们之间的依赖和用法。而且我们开始引入易测试性的概念，才发现，如果我们已经写了测试，不分出来才是更安全的。我们感觉用上面的方式写出来的代码会很混乱并且还和安卓api紧紧地耦合，这样阻碍了我们做jvm测试也制约了简单设计测试用例。这种就是以Activity和Fragment作为控制器（Controller）的经典MVC模式。

所以，我们将阐述一些原则，根据这些原则小心的实现，我们将会解决上面提到的大部分问题。这些原则我们称做MVP（Model-View-Presenter）设计模式

什么是MVP设计模式

如果参照MVP模式进行设计，代码之间的关联减弱了，使得代码的可重用性和可测试性都得到了加强。这种架构以组件在应用中所担负的任务来进行分割，这也称作分离概念。

MVP将应用分成三种基本的组件：

1.Model：它的职责是处理应用数据的部分

2.View：它的职责是在屏幕上布局显示指定数据的视图

3.Presenter：它是一个连接Model和View的桥梁。也是扮演指挥view的角色。

根据以上提到的组件，MVP可以列出以下一些基本的规则：

1.Presenter控制View来画UI，View是应用中被控制的部分。

2.View将委托用户所有的交互行为给Presenter处理

3.View从不直接从Model获取数据

4.Presenter是负责委派View的请求给Model和根据特定的事件要求View做出相应的动作

5.Model的职责是从服务器、数据库、文件中抓取数据

以上提到的原则可以用许多的方法来实现，每个开发者都会有自己的实现。但并不会的大的出入

根据MVP模式，我先写下序文

1.Acitivity、Fragment和自定义View在应用中扮演View的部分.

2.每一个View都有一个它对应的Presenter.

3.View通过一个接口（Interface）和它对应Presenter连接。反之亦然.

4.Model被分成几个部分：ApiHelper, PreferenceHelper, DatabaseHelper, 和FileHelper.这些所有的数据渠道会在数据管理（DataManager）中实现，也就是数据管理将所有的Model进行统一管理.

5.Presenter通过接口调用DataManager的实现.

6.DataManager（数据管理）只有被调用的时候才进行服务.

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

很显然，以上信息可以在各种博客中或者从安卓官方对MVP的介绍中找到，那这篇文章的核心是什么呢？

核心：将MVP架构在应用中实现起来

通过分析一个简单的Activity例子：由于应用中有很多的组件，当我们都尝试着绑定到Activity中的时候，这些组件使得我们很混乱。从这个例子看似MVP的出现很简单。

首先，让我们描述这个架构蓝图

不管你从事什么软件工程，架构都是一件首要考虑的事情。一个小心地精心设计的框架不但提供一个很好的扩展性而且在将来还能减少大量的重复工作。现在很多项目都是一个团队来开发，因此，项目代码的可读性和模块性在架构设计中应该被视为至关重要的要素。我们也有大量的依赖第三方一些库和不断得更换方案由于使用的场景、bugs和支持。所以我们的架构应该设计成即插即用的设计。接口（Interface）在类中的运用就是这个目的。

上面画出来的安卓架构蓝图包含所有的特性和是基于MVP蓝图。

你看接下来的内容可能会觉得不是那么清楚，但只要你看过这篇文章对应下一部分给出的例子，这些概念你将会很清楚了

让我们来理解概略架构中每一部分

• View：这是应用的一部分，主要用来渲染UI和接受来至用户的交互。主要由Activity，Fragment和CustomView（自定义view）构成

• MvpView : 由View来实现的一个接口，这个接口包含的方法都是暴露给它对应的Presenter使用的。

• Presenter：它的数量主要取决于View的数量并且它是一个不连接安卓API的纯java类。它从对应的View中接收用户的交互信息，然后做一些业务逻辑判断，最后引导View运行一些指定的行为。它也可以通过数据管理（DataManager）获取业务逻辑需要的任何数据。

• MvpPresenter：由Presenter来实现的一个接口。它包含的方法主要是给它对应的View调用的。

• AppDbHelper:应用中的一部分，主要是数据库管理和所有处理与数据库相关的数据。

• DbHelper：由AppDbHelper实现的一个接口和包含暴露给应用组件调用的方法。这层可以解耦任何指定实现DbHelper，因此使得AppDbHelper成为即插即用的模块。

• AppPreferenceHelper：这个就像AppDbHelper一样，只不过它的主要任务是从安卓share preference读写数据。

• PreferenceHelper：和DbHelper一样的接口，只不过由AppPreferenceHelper来实现。

• AppApiHelper：主要管理网络相关的API调用和数据处理。

• ApiHelper：和DbHelper 一样的接口，只不过由AppApiHelper来实现。

• DataManager：由AppDataManager来实现的一个接口。它包含并暴露所有数据处理相关的操作方法。理想上，它所有实现委托给提供服务的所有Helper 类。对于这个DataManager接口，它继承了DbHelper, PreferenceHelper 和ApiHelper 接口.

• AppDataManager：在应用中，它是一个联系任何数据相关的操作。DbHelper, PreferenceHelper 和 ApiHelper 只为DataManager效劳。它委托所有的实现给指定的任何的Helper。

现在我们熟悉了所有的组件和它们在一个应用中扮演的角色。我们现在将在这些各种各样组件中制定交流的模式。

• 应用（Application ）类实例化AppDbHelper （赋值给DbHelper 变量），AppPreferenceHelper （赋值给PreferenceHelper 变量），AppApiHelper （赋值给ApiHelper 变量）和最后将DbHelper、PreferenceHelper 和PreferenceHelper 引用传给AppDataManager（赋值给DataManager 变量） 进行实例化。

• View 组件实例化它对应的Presenter，并传给MvpPresenter引用。

• Presenter接收它的View组件和并通过MvpView引用它，Presenter也接收DataManager。

• DataManager 作为一个单例存在。

这就是应用去实现MVP模式的一个基本参考。

就像一个外科医生谈论外科手术过程一样，谈论并没有什么用处，只有他执行和实践，才能看到效果。只有我们真正的行动起来，我们才能理解和实现这个想法

下一部分，我们将探究真正实现app的例子和希望能更好的理解和掌握相关的概念。
[第二部分链接]（https://blog.mindorks.com/essential-guide-for-designing-your-android-app-architecture-mvp-part-2-b2ac6f3f9637#.i825tgjrg）
欢迎交流