android MVP 架构思路

android MVP 架构思路

概念

mvp是一个新的android开发架构，在之前的mvc的基础上进行修改，目标是使得逻辑和显示解耦,达到模块化。

关于它俩之间的区别，可以在下面地址查看

http://blog.csdn.net/boyupeng/article/details/46884823

具体

View 主要显示界面使用。通过调用 Presenter 的接口，实现回调响应，更新数据。

Presenter 主要作为一个桥梁，Model 去访问一个网站数据，解析回来，通过View 接口提供给界面显示

Model 主要数据结构，作为实现逻辑业务的核心

具体关系图为：

优缺点

• 优点
  • 界面和逻辑业务通过接口关联，将业务实现细节隐藏，如此一来，当我们将交互之间的接口定义好之后，内部的实现细节修改，保证模块独立性。
• 缺点
  • 正是因为使用了接口来解耦模块之间的关联，因此会出现接口类增加，可以适当的使用MVP模式，在一些很简单的逻辑业务里面，可以不采用MVP。

这个开发架构，在慢慢演变，出现了一种思路，就是将Model继续分解，出来一个管理Model的DataManager,对Model进行统一管理。

有了这个DaraManager之后，Presenter不直接对应Model,而是对应调用DataManager的接口，DataManager内部实现各个 Model 的实现细节。

下来为了更好地理解MVP的思路，我们看下官方的MVP demo

地址如下： https://github.com/googlesamples/android-architecture/tree/todo-mvp/

View 区别 这里的View和android 默认的View的意义不一样。默认的指的是TextView Button这类叫做View，这里的View指的是界面视图，比如Activity 或者Fragment，在我们当前的例子里面，就是Fragment了。

我们首先来到主Activity里面，这里为TasksActivity

我们看到这里定义了一个mTasksPresenter.随后构造了一个TasksFragment，然后使用

将Presenter和对应的View（这里便是TasksPresenter和tasksFragment关联起来），创建TasksPresenter的时候，使用mTasksView将View存下来，为的是后面获取数据回来，调用View的接口，去更新View数据。使用

将View的mPresenter赋值。随后我们界面上需要请求，或者获取数据的时候，直接调用mPresenter提供的接口，mPresenter获取回来的结果，通过保存的View对象，调用接口即可。

为了更好的来说这里定义了什么，我们直接来看demo里面定义的接口。 这里我们看下TasksContract这个类，可以看到里面有两个接口，分别为：View和Presenter，具体如下：

View里面定义我们获取的数据，都有哪些方式交给VIew显示，刷新。

Presenter里面定义我们为了准备提供给View的数据，需要实现哪些方法。 如此一来，我们将View完全作为了被动处理数据，不主动参与数据的如何来的，只是处理各个给过来的数据。依据事先约定的各个接口的功能，拿到数据，进行界面的更改，列表的刷新等等。

就以我们上面讲的TasksPresenter 和对应的tasksFragment来看，我们看下它们的类的定义方式。

这样子做完之后，TasksPresenter实现TasksContract.Presenter的方法，tasksFragment实现TasksContract.View的方法。

然后我们通过在tasksFragment里面调用mPresenter的各个方法，触发Presenter去获取数据，拿到数据回来，直接调用事先关联的View（这里便是tasksFragment）各个方法，来完成一个来回。

这里我们看下点击fab按钮的一个操作时序图，会直观的看到这个View和Presenter的传递过程。

看的仔细的伙伴，会发现这里都是V和P（View和Presenter）之间的事情，没有看到M（Model），为什么呢？

因为Model是属于跟Presenter关联的，跟View是不直接联系的。Presenter请求数据的时候，具体的实现过程会后推给Model来处理，Model处理数据，返回给Presenter，Presenter整理下，然后传给View，完成一个流程。

这里我们看下刷新界面的一个操作时序图：

不知如此来看，是否能清晰的理解这个开发模式呢？欢迎留言反馈。