最近分别在两次迭代中采用MVP结构重构了业务模块，谈谈对MVP的理解
一般文章上来先介绍MVP分别是什么，换个思路来梳理MVP
一，Concept
Action vs UI
Actions vs UIs
Presenter vs View
对业务的具体的操作即是Action，例如login
对某一时刻界面的展示即是UI, 例如login edittext
Action 与UI之间的关系是：
1，Action Manager告诉UI处于什么状态，例如：
onLoginSucceed（）
onLoginFailed（）
2，View（UI）被触发时，向上报给ActionManager（Presenter）执行相应的Action。例如点击登录/登出按钮时触发：
login（）
logout（）
二，Interface-oriented Programming
面向接口编程，其实是面向抽象编程。
抽象指的是不涉及细节实现的协议，而定义（Action的）能力或（UI的）状态。
简单起见，你可以把presenter理解为可以执行很多action的manager。
先定义IloginPresenter的能力：
Note:
用最通俗的话就是说你可以让presenter干一些事情，也可以问一些你感兴趣的事情。
login（String username， String password）
logout（）
isLogin（）
再定义IloginView的状态：
onLoginSucceed（）
onLoginSucceed（）
onLoginFailed（）
三，Single Invoke
废弃MVC中M和V之间的调用关系，改用一种更单纯的调用，那就是我真的是在问你，而不是只是让C透传一个数据而已。
四，Model
在复杂业务下，Model的构成可能是多个的，我们不一定需要定义一个MixedModel，可以简单的把多个data传给presenter就行。
Model是层的概念，而不是单一数据结构。给presenter提供执行或者判断所需要的数据支持。
五，常见问题
1，model被当做一个大数据在presenter和view中间传来传去
2，modle被定义为一个大而复杂的数据结构
3，view中lisenter中不应直接处理ui，而应该将事件传递给presenter，让presenter作为总分发。
4，业务划分上presenter定义的颗粒度不够，导致其他地方单独调用会麻烦。在业务上需要抽象为独立的presenter，而不应该局限在UI的整体性。一个view是可以绑定多个presenter的。
例如，支付页面的价格bar，除了有价格展示，还有文案展示，应该抽象为两个presenter：
a， PricePresenter
b， PriceInfoPresenter
M
V
P
