MVP模式的一点思考：简化系统架构，而不是搞的更复杂

最近打算写一个“纯正”的 MVP 程序&＃xff0c;结果发现越搞越复杂&＃xff0c;发现很容易陷入 Presenter 滥用的陷阱。今天清理一下思路&＃xff0c;写个小总结。

一个合理的调用流程应该是 A-B-C-D&＃xff0c;或者 A-B-C&＃xff0c;或者A-B。也就是说&＃xff0c;View 需要访问 Model 时&＃xff0c;才需要向 Presenter。如果不需要访问 Model&＃xff0c; 则完全不必访问 Presenter。例如&＃xff0c;流程 A-D 纯属脱裤子放屁&＃xff0c;多此一举。

因此&＃xff0c;Presenter 中的所有方法&＃xff0c;都是需要访问 Model 的&＃xff0c;如果不需要访问 Model&＃xff0c;该方法则是冗余的。因此&＃xff0c;合理的调用过程必须包含步骤 A-B。

考虑到 Presenter 中可能存在工作线程&＃xff0c;B-C-D 的调用过程应该是合理的。

View 自己能处理的事情&＃xff0c;尽量不要通过 D 来调用 IView&＃xff0c;绕一圈子再回来处理。

先写这么多&＃xff0c;等我完成手头的任务&＃xff0c;再写一份详尽的总结。&＃xff0c;手头的代码需要重构一下了。

简化 Presenter 和 IView&＃xff0c;能使的系统设计更容易适应需求的变化。事实上&＃xff0c;系统结构越复杂&＃xff0c;软件设计就越具象化&＃xff0c;就越难适应需求的变化。

以前读过一篇文章说&＃xff0c;Presenter 的接口方法一定是 void onXXXX() 的形式&＃xff0c;不需要返回任何错误信息。其实这样做很荒唐&＃xff0c;如果不能返回信息&＃xff0c;必然造成需要 Presenter 通过 IView 接口调用 View 的方法显示错误信息&＃xff0c;严重增加系统的复杂性。

我觉得 Presenter 的方法如果能返回错误信息&＃xff0c;能明显简化系统逻辑关系。