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

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

1. Presenter 必须访问 Model

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

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

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

调用过程	合理性
A-B	ok
A-B-C	ok
A-B-C-D	ok
B-C-D	ok
A-D	x
D	x

2. IView 接口尽量简单化

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

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

3. 简化 Presenter 和 IView 的好处

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

4.一点思考

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

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