MVP 架构模式
Last updated
Last updated
框架模式高于设计模式，是对多人协作、多个代码模块进行组织的方法，框架模式更像大智慧，而设计模式更像小技巧。
有人说，基础框架要追求抽象、灵活；但具体的功能模块、函数不必追求过于精妙的模式。 私以为上述两个说法在工程实践中是有道理的。颇有种识得大巧不工的味道。架构模式变种很多，毕竟从MVC到MVVM的提出也间隔了20年了。有些知识需要精确的理解，有些则因为需要自行变通而在学习的时候观其大略。架构模式无疑是后者。
本篇就来谈谈目前我对几种客户端架构模式的粗浅理解，尤其适用于UI部分。
首先一图以蔽之。
A发送事件，B接收事件。A对B可以是无感知的，B的实现变了（例如换了一个库），A通常并不需要做什么改变（因为随着事件抛出的通常只是数据），即A和B无耦合。而A调用B的接口，就使得A必须劳神去照顾B的变化。这么一说好像调用接口不怎么优雅，但调接口真的很直接很方便！ 另一个小区别就是，事件可以被多个监听者接收，这取决于项目中采用的消息机制。而调用接口嘛，虽然也可以（将所有被调用者的公共部分抽象成一个 interface，A去调用interface里对应的函数），但似乎麻烦了点。
粗暴地理解就是业务逻辑和数据放在Model里，UI（文本、图片、动画、菜单啊）就是一个个View（或者subView），这两个东西一定要分开，不然代码量一多，就变成了一团毛球，极难维护。那 model 和 view 之间的联系由谁负责呢？由此，就产生了不同的框架模式。
上面的图中，重点画出了三者的区别。首先说MVP。为什么叫P（Presenter）就不解释了，但可以发现，Model和View对外界都是无感知的，只需发出事件。所有的活儿交给P，P一面监听事件，一面调用下一步的接口——饭都喂到嘴边了啊。借用一些家庭主妇的口头禅就是：你们呢爷儿俩都是甩手掌柜！
MVC，三者形成了一个环。与MVP最大的不同是，MVC中的View包含了来自Model的事件处理逻辑，也就是View依赖于Model。C的任务就减轻了，只负责上传，以后的事情，你俩自己看着办。这是最经典的架构模式，
MVVM，V为了分担一部分压力，与中间的View Model达成了一个“协议”，VM你按照这个协议将状态数据设置好，那么我就自动根据这些状态数据来改变自己的表现。这就叫双向绑定。实现方法：简单的如手写 get/set，然后有些现成的sdk可能基于get/set封装了一层api。还有的思路据说是不停地轮询，看状态有无变化。或者用观察者模式。 这样相比于MVP，好处是不至于“接口爆炸”，接口那么多，谁知道该用哪个！我们码农的记忆力也是有限的。
MVP将Model和View彻底解耦和了，而且容易理解，可能我还没悟到MVVM的双向绑定的妙处吧，但业内的共识是：双向绑定使得bug更难定位了。在写游戏UI的过程中，觉得MVP用起来比较自然，而且在这种思路下，可以进一步扩展，例如下图。图中Model之间也可能有事件监听的需要。
