MVP是什么?
Model-View-Presenter是一个分离关注点的软件架构。Presenter作为Model和View之间的桥梁,用于演示业务逻辑。三者之间的交互关系如下:
解读以上MVP分析图:
1. View:
在MVP中,view是重新被定义了:
在Presenter中接受命令的View叫做View 。一般由是Fragment和Activity充当角色。
android.view.View在MVP架构中是叫做Android View 。误混淆View和Android View混淆概念。
使用Fragment的原因:
Activity和Fragment之间的分离很好的适合MVP实现,Activity是创建和连接views和Presenters.
- 平板电脑中布局或者屏幕中多个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 。 除开这些,功能模块还具备以下:
Contract: 用于定义View和Presenter的合同
Activity: 负责创建Fragments和Presenters.
Fragment: 实现View的接口
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