网上对应的逻辑介绍比较多,推荐以示例代码讨论更方便理解,以github上的示例项目 Androidmvp 为例,个人感觉就是面向接口编程,高度解耦,View与Model通过Presentor作为桥梁连接。View只负责展示,Model只负责后台处理并告知(通过回调)处理结果,Presentor在预先定义好的回调实现中,使用View的引用(该引用在Presentor的初始化时由View告知Presentor)操作界面变化。
Model
MVP模式解决了MVC下臃肿的Activity的问题。特别是Model那层,通过定义接口以及规定了回调接口。感觉就是定义了一组后台的服务调用,并且有配套的回调接口需要调用者实现,当服务被Presentor调用之后,根据执行情况调用对应的回调接口,整个解耦非常漂亮。而且,当Model有替换时,Presentor几乎不用改动,除非有新的回调接口需要Presentor实现。
Presentor
Presentor,调用Model,也就是后台,并且在提供Model的回调函数里面操作view绘制新的信息。当然,presentor作为一个承上启下的中间层,可以在提供的接口实现中组合UI的显示,这样,也算是最大限度地讲业务逻辑和实现UI分离。这里有一个小技巧,为什么用回调不用函数返回值来做。原因如下:
- 回调可以做成异步操作,如果等返回,那么对于时间敏感的操作就有问题了。
- 有时候,根据返回值的后续操作可能会有不同,比如onSuccess,onFailure,onTerminate等,通过回调函数直接调用可以简化逻辑,而不需要额外加一层if判断。
View
View层,就是一个不要对自己有任何想法的模块,一切变化,通过presentor来驱动。View里面如果有对业务逻辑的判断,那就想想自己是不是哪儿错了。