最近由于感觉和同事之间对MVP的理解有所差异,我重新审视了一下MVP的写法,对目前项目中出现的一些问题进行了思考,创造出一种MVP的变形,我暂且称它为MCVP。文末有demo。
MVP
对基础内容不感兴趣的同学可以直接跳到MCVP的部分。
MVP是为了解决传统Android开发架构MVC引起的问题的解决方案之一:Activity在MVC架构中既担当了View又充当了Controller的角色,最后成为上帝类并且类代码量爆炸,即使单独分离出Controller类,情况仍然没有得到多大的改变,只是换了一个上帝而已;这时候MVP被推荐出来,它遵从依赖倒置原则解耦了原来意义上的Activity(View)和Controller(Presenter),通过接口抽象行为使我们的UI和业务逻辑分离并得以复用。
这是一张随处可见的MVP模式图,重申一下MVP的基本概念:
View一般指Activity和Fragment,它们承载用户的UI界面,和用户直接交互。
Model指数据源,它是负责获取和保存数据的对象的集合,而不是特指某一个实体或者叫model的接口,用层的概念来描述它更加合适--Model层。
Presenter是View和Model之间的协调者,负责处理业务逻辑、承接业务逻辑。
View和Presenter之间使用接口调用进行解耦,接口上的方法应该是它们具体行为的抽象:作为调用者去调用对方的方法,它会有一个意图,是 i want to do;而被调用者的暴露方法,就是what i can do的集合。至于对方内部是到底怎么实现的,调用者丝毫不需要关心。 而Model是否应该使用接口进行抽象呢?我觉得大部分应用都没这个必要,Model接口的维护成本比较高,带来的价值也不大,除非你的数据源真的有多个实现,例如在不同情况下使用不同的服务器数据库,可以考虑用接口解耦。
MVP模式大致分为两种写法,被动视图(Passive View)和监督控制器(Supervising Controller)。被动视图中View把逻辑和与Model的交互全权交给Presenter,甚至自己的表现也由presenter控制,什么都不需要管;监督控制器中Presenter只是一个逻辑辅助的职能,View会部分接触修改到Model的数据,但是我认为这是被动视图也无法避免的,例如列表显示总要依赖实体类,所以我也更倾向于监督控制器写法。
以上不过是我个人理解,欢迎互相讨论。
经常会出现的问题
很多小伙伴对MVP甚至是对面向对象的基本原则理解得不够,于是出现很多奇奇怪怪的问题,包括但不限于以下问题:
- 创建出IModel接口,为每一个不同的IPresenter接口实现一个Model类,IPresenter和IModel通过Contract关联一起,这样不仅出现了很多Model类,也一并出现了非常多的冗余代码。正如我上面所说,Model实际上是一个集合,一个Model层的概念。这张图更加能说明情况。
-
和第2点一样的问题,没有对View和Presenter的行为进行抽象,Presenter过多参与控制View的显示,违反单一职责原则,甚至出现对某些个View控件进行直接操作的情况。接口只暴露行为的抽象,具体的操作细节不应该暴露出来。
-
View的全部点击事件使用某种唯一参数传达给Presenter的某个特定方法,在Presenter对参数集中进行判断执行。出现这种情况也是没有对行为进行抽象。View犹如行尸走肉,完全没有i want to do的意图,就像是把石头丢入黑洞,至于黑洞里面发生了什么事、会发生什么事?I don't know。好好想一想,View-UI作为与用户交互的平台,用户从UI点击某个图标的时候,用户到底有没有意图?那么UI的事件应不应该有意图?
- Presenter知晓了Android框架的东西。Intent的数据获取和传递、onActivityResult()的返回处理,这些都是Android框架的部分,应该交回View去处理。往大说是Presenter不要依赖Android环境便于测试,往小说是Intent数据的定义、startActivity()都是activity、fragment的事,你一个Presenter掺和啥呢?
MCVP
上面说了很多奇怪但是不一定会在你项目里面出现了问题,其实它们不是重点,接下来这个问题我相信应该有出现过在你项目里,或者你看过的项目里。
场景与需求:提交订单的页面,提交订单之后会提示可以升级你的订单,升级后能够获得更好的售后服务,但要收取少量服务费,而这个订单是否能够升级,是由后台动态配置。
流程如图所示:
代码大概是这样的(伪代码不用太纠结细节,我们注意看思路即可):
public interface SubmitOrderContract {
interface IView {
void askUserForUpgrade(CallBack<Boolean> callback);
void onSubmitSucceed();
void onSubmitFailed();
}
interface IPresenter {
/**
* 提交订单
*/
void submitOrder(SubmitOrderEntity order);
}
}
复制代码
public class SubmitOrderActivity extends AppCompatActivity implements SubmitOrderContract.IView {
...
@Override
public void askUserForUpgrade(final CallBack<Boolean> callback) {
final InquiryDialog dialog = new InquiryDialog(this);
dialog.setOnResultListener(new InquiryDialog.OnResultListener({
@Override
public void onResult(boolean result) {
dialog.dismiss();
callback.onResult(result);
}
});
dialog.show();
}
...
}
复制代码
public class SubmitOrderPresenter implements
SubmitOrderContract.IPresenter {
...
@Override
public void submitOrder(final SubmitOrderEntity order) {
mApi.submitOrder(order, new HttpApi.HttpListener<SubmitResultEntity>() {
@Override
public void onCallBackOk(SubmitResultEntity result) {
if (result.canUpDate) {
mView.askUserForUpgrade(new CallBack<Boolean>() {
@Override
public void onResult(Boolean p) {
submitOnUpgrade(p, order);
}
});
} else {
mView.onSubmitSucceed();
}
}
});
}
private void submitOnUpgrade(boolean isContinue, SubmitOrderEntity order) {
if (!isContinue) {
mView.onSubmitFailed();
return;
}
mApi.submitOrderForUpgrade(order, new HttpApi.HttpListener<SubmitResultEntity>() {
@Override
public void onCallBackOk(SubmitResultEntity submitResultEntity) {
mView.onSubmitSucceed();
}
});
}}
复制代码
发生的问题
这发生了两个问题:
- 业务逻辑流割裂。我们的业务代码由于需要View的弹框询问而断裂成submitOrder()和submitUpgradeOrder()两个方法,导致逻辑不连贯。
- 逻辑泄露。在Presenter的视角来看,提交订单的一系列流程并不是Presenter自己可知可控的,虽然submitUpgradeOrder() 是提交订单流程的一步,但是Presenter自己完全不知道什么时候会被触发,submitUpgradeOrder()的触发逻辑被把握在View手里,View把握了业务逻辑!
解决方案
针对这种特殊场景,我给出的解决方案是:
MCVP MCVP MCVP MCVP MCVP
即 Model-CallbackView-Presenter。 看到CallbackView这个词,聪明的同学可能已经猜出了答案,是的,意思是一个会回应的View。MCVP是MVP的一个特殊变体,可以随时运用到你的项目里。
在Presenter这个角色的视角中,询问用户是否升级订单,不过是一个异步获取数据的过程而已,我们完全可以把View看成是一个数据源,仿照网络请求的方式等待用户选择结果返回。
View只需要询问用户是否确认然后告诉Presenter就足够了,甚至不需要知道Presenter要它询问用户确认些什么东西。就像菜贩子和顾客的关系,菜贩只要知道顾客需要什么蔬菜,而不需要知道顾客买这个瓜回去干些什么,完全的解耦关系。
当我们选择这种方案,传递给View的入参变成了带有泛型的回调接口Callback,View只知道我们需要它回答什么(泛型T),它通过Callback接口回调过去即可。
优点
MCVP完全避免了业务逻辑的断裂,保持了流程的连贯,presenter对于逻辑流程完全可知,提 高了逻辑可读性,类中的业务逻辑方法内聚性更加高,你可爱的业务逻辑终于不需要再在View和Presenter的实现上跳来跳去了,刚接手代码的人也简单清楚逻辑流的走向,维护性也提高了;而且完全符合被动视图的写法,View也不会因此接触到任何实体类。解决了上面所述的两个问题。
看一下MCVP的代码:
public interface SubmitOrderContract {
interface IView {
void askUserForUpgrade(CallBack<Boolean> callback);
void onSubmitSucceed();
void onSubmitFailed();
}
interface IPresenter {
/**
* 提交订单
*/
void submitOrder(SubmitOrderEntity order);
}
}
复制代码
public class SubmitOrderActivity extends AppCompatActivity implements SubmitOrderContract.IView {
...
@Override
public void askUserForUpgrade(final CallBack<Boolean> callback) {
final InquiryDialog dialog = new InquiryDialog(this);
dialog.setOnResultListener(new InquiryDialog.OnResultListener({
@Override
public void onResult(boolean result) {
dialog.dismiss();
callback.onResult(result);
}
});
dialog.show();
}
...
}
复制代码
public class SubmitOrderPresenter implements SubmitOrderContract.IPresenter {
...
@Override
public void submitOrder(final SubmitOrderEntity order) {
mApi.submitOrder(order, new
HttpApi.HttpListener<SubmitResultEntity>() {
@Override
public void onCallBackOk(SubmitResultEntity result) {
if (result.canUpDate) {
mView.askUserForUpgrade(new CallBack<Boolean>() {
@Override
public void onResult(Boolean p) {
submitOnUpgrade(p, order);
}
});
} else {mView.onSubmitSucceed();
}
}
});
}
private void submitOnUpgrade(boolean isContinue, SubmitOrderEntity order) {
if (!isContinue) {
mView.onSubmitFailed();
return;
}
mApi.submitOrderForUpgrade(order, new HttpApi.HttpListener<SubmitResultEntity>() {
@Override
public void onCallBackOk(SubmitResultEntity submitResultEntity) {
mView.onSubmitSucceed();
}
});
}
}
复制代码
可以看到,所有业务流程都在submitOrder()中,没有跳出这个方法,submitOrder()非常忠实地完成了它提交订单的任务,没有再假手于人(View)了。
有同学说出现了回调地狱啊~那很好解决,相信大家都知道解决方法,Rxjava、协程...它们都可以解决。由于篇幅原因,RxJava代码的部分可以看文末传送门看demo。
缺点
MCVP有它的优点,但我也承认它也有自己的缺点:
- Callback只能使用一次,而且要保证它不会被调用两次,不然你后面的逻辑就走两遍了,但只要记住这个情况存在,基本不会出幺蛾子。
- 由于Callback的存在,View需要持有Callback这个对象,存放成全局变量(一个即可)或者每次创建你的UI(就像例子中的dialog那样),不过这我觉得其实不算是个问题,全局变量只是个小小的杂质,不影响它带来的优点。
MCVP只不过是CallbackView与MVP的结合,这个思想完全可以移植到其他模式上。除了我的举例,它应该会有更多写法,例如从View方法返回Callback而不是Presenter提供Callback,我也会继续继续思考优化MCVP,期待它能够在更多场景发挥作用,使我们的代码结构变得更加好。
谢谢你的观看!
周末看比卡超去吧~!