Android MVP架构

MVP是什么？

---

Model-View-Presenter是一个分离关注点的软件架构。Presenter作为Model和View之间的桥梁，用于演示业务逻辑。三者之间的交互关系如下：

解读以上MVP分析图：

1. View：

在MVP中，view是重新被定义了：

1. 在Presenter中接受命令的View叫做View 。一般由是Fragment和Activity充当角色。

2. android.view.View在MVP架构中是叫做Android View 。误混淆View和Android View混淆概念。

使用Fragment的原因：

1. Activity和Fragment之间的分离很好的适合MVP实现，Activity是创建和连接views和Presenters.

   1. 平板电脑中布局或者屏幕中多个view采用Fragment框架的优势。

2. Presenter:

作为View与Model的中间枢纽，操作View(更新UI),操作Model(传递用户的UI动作，进行业务处理)，处理逻辑业务

3. Model:

 数据源（远程和本地），读写本地数据或者与后台服务器交互数据。

注意点：

• View不与Model直接交互，而是通过与Presenter交互来与Model间接交互。

• Presenter与View的交互是通过接口来进行的，更有利于添加单元测试

• 通常View与Presenter是一对一的，但复杂的View可能绑定多个Presenter来处理逻辑。

项目中每个功能模块有哪些角色？

每个功能模块都自己的 view , presenter , model 。 除开这些，功能模块还具备以下：

1. Contract: 用于定义View和Presenter的合同

2. Activity: 负责创建Fragments和Presenters.

3. Fragment: 实现View的接口

4. Presenter: 实现Presenter的接口

通常来说，业务逻辑是存在Presenter中，并且依赖View去实现UI更新。

View中不包含业务逻辑，它将Presenter的命令转换成UI动作，且监听使用者的动作，将使用者动作传递给Presenter

Contracts是一个接口，用于定义Presenter和View间的连接。

为什么使用MVP?

MVP架构提高了代码的可测试性，可读性，可扩展性。这些改进是通过分离问题来实现的：它可以是轻松测试（单元和UI）,较小的类别大小，并且可以更轻松的更改数据或者UI.

降低耦合性，模块职责划分明显，代码复用，数据影藏，代码灵活。

资源参考：

• Android Architecture Blueprints（架构蓝图）：http://blog.csdn.net/hexingen/article/details/72057781