Android架构模式-MVP

MVP的基本概念

传统的Android应用开发中，View层（Activity，Fragment或者自定义View）承载了太多的责任，他不仅要完成页面的更新，复杂动画的渲染等UI相关操作，还要处理各种业务逻辑，例如网络获取数据，讲用户输入保存的本地数据库中。由于职责不单一，View层的代码往往显得很庞大，一个Activity或者一个Fragment的代码行数可能要好几千行。这种模式显然不是长久之计，为了更好的进行分层设计，我们有必要引入MVP设计模式。

MVP的全称是Model，View，Presenter，顾名思义，它将整个应用分为三层，如图所示

• View层：
  视图层，包括页面相关的功能，例如各种Activity，Fragment，View，Adapter等，该层专注于用户的交互，实现设计师给出的界面。View层一般会持有Presenter层的引用，或者通过依赖注入的方式获得Presenter的实例，并将非UI的逻辑操作委托给Presenter。
• Presenter:
  逻辑控制层，充当中间人的角色，用来隔离View层和Model层，该层是通过从View层剥离控制逻辑部分形成的，主要负责View层和Model层的控制住和交互。例如接收View层的网络数据加载请求，并发给对应的Model处理，同时监听Model层的处理结果，最终将其反馈给View层，从而实现页面的刷新
• Model层：封装各种数据来源，例如远程网络数据，本地数据库数据等，对Presenter提供简单易用的接口

MVP与MVC的区别

MVP是经典的MVC的延伸和改进，MVC的关系图如图

和MVP的相比，可以看出最大的不同在于

• MVP中View层和Model层并没有直接通信，而是通过中间人Presenter来间接通信，Presenter和View以及Model的交互都是通过接口进行的；通常View与Presenter是一对一的，当然，复杂的View可能需要多个Presenter来共同处理，这些需要根据具体的业务需求而定。
• MVC中Model层和View层是直接通信的，而且Controller是基于行为的，可以被多个View共享

MVP的开源实现

• Google官方推出的Android UI 架构

MVP的好处

使用MVP组织代码架构，并对代码实施分层管理，有一下好处

• 如果界面发生变化，甚至全新改版，只需要修改对应的View即可，Presenter和Model层无需更改
• 如果业务逻辑或者数据获取发生改变，只需要修改对应的Model。
• 如果控制逻辑发生改变，只需要修改对应的Presenter
• Presenter层和View层以及Model层的交互都是基于接口实现的，这有利于对Presenter进行单元测试，同时由于是面向接口编程需要事先定义好接口，加快开发。

MVP存在的问题

• 增加代码类的数量
• 开发难度大