最近分别在两次迭代中采用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
网友评论