android MVP应用架构模式

MVP模式的全称是：Model View Presenter

 

 

 

MVP模式解除View与Model的耦合,MVP模式解除View与Model的耦合，同时又带来了良好的可扩展性、可测试性，保证了系统的整洁性、灵活性。

可能对于简单应用来说，MVP稍显麻烦，各种各样的接口与概念，使得整个应用充斥着零散的接口，但是对于比较复杂的应用来说，MVP是一种良好的架构模式，它能够非常好的组织应用结构，使应用变得灵活，拥抱变化。

 

MVP模式可以 分离 显示层 和 逻辑层，它们之间通过接口进行通信，降低耦合度。理想化的MVP模式可以实现同一份逻辑代码搭配不同的显示界面，因为它们之间并不依赖于具体，而是依赖于抽象。这使得Presenter可以运用于任何实现了View逻辑接口的UI，使之具有更广泛的适用性，保证了灵活度。

 

一般而言，业务逻辑和数据存取是紧耦合的，很多人会将各种各样的业务逻辑塞进某一个Activity、Fragment或者自定义View类 中，使得这些组件的单个类型臃肿不堪，其中又有一些异步任务，导致某个类超过千行代码。当然，对于功能复杂的应用来说，一个类超过千行代码很正常，但是重点是：业务逻辑与View元素严重地耦合在一起导致了类型膨胀的问题。

 

对于一个可扩展、稳定的应用来说，我们需要定义分离各个层，主要是UI层、业务逻辑层和数据层。毕竟，我们不知道以后还要加入什么逻辑，是从本地数据库检索数据？还是从远程的服务器中？我们的UI、数据库是否会被替换？例如，随着产品的升级，我们的UI可能会被重新设计，若UI发生了变化，此时由于业务逻辑耦合在View中，UI变化导致我们修改新的View控件，此时，你就需要到原来的View中去抽离具体的业务逻辑。

 

 

MVP模式可以让UI界面和数据分离，我们的应用至少可以分为3层，这样使得我们也可以对这3个层次进行独立的单元测试。MVP模式可以让我们从Activity、Fragment等View角色中分离大部分代码，使得每个类型的代码量大幅减少，职责单一，易于维护。

 

 

MVP并不是一个标准的模式，它有很多实现方式，它可以随着Presenter的复杂程度变化。只要保证我们是通过Presenter将View和Model解耦合、降低类型复杂度。各个模块可以独立测试、独立变化，这就是正确的方向。

 

 

在Android开发中，大多数人可能会把Activity、Fragment作为View角色来看待，因为它的职责是加载并且处理一些简单的与View相关的逻辑，它组织与管理View集合，我们可以把它看成粗粒度的View，当然，你也可以将它们看成Presenter。

 

MVP模式的三个角色

1.Presenter——中间人

Presenter主要作为沟通View和Model的桥梁，它从Model层检索出数据后，返回给View层，

使得View和Model之间没有耦合，也将业务逻辑从View角色上抽离出来。

 

2.View——用户界面

View通常是指Activity、Fragment或者某个View控件，它含有一个Presenter成员变量。通常View需要实现一个逻辑接口，将View上的操作通过Presenter成员变量转交给Presenter进行实现，最后，Presenter调用View逻辑接口将结果返回给View元素。

 

 

3.Model——数据的存取

对于一个结构化的App来说，Model角色主要是提供数据的存取功能。Presenter需要通过Model层存储、获取数据，Model就像一个数据仓库。或者说是：Model是封装了数据库DAO或者网络获取数据的角色，或者是两种数据获取方式的集合。

 

参考《Android源码设计模式》