MVP 模式初探

网上对应的逻辑介绍比较多，推荐以示例代码讨论更方便理解，以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里面如果有对业务逻辑的判断，那就想想自己是不是哪儿错了。