MVP 架构模式

框架模式高于设计模式,是对多人协作、多个代码模块进行组织的方法,框架模式更像大智慧,而设计模式更像小技巧。

有人说,基础框架要追求抽象、灵活;但具体的功能模块、函数不必追求过于精妙的模式。 私以为上述两个说法在工程实践中是有道理的。颇有种识得大巧不工的味道。架构模式变种很多,毕竟从MVC到MVVM的提出也间隔了20年了。有些知识需要精确的理解,有些则因为需要自行变通而在学习的时候观其大略。架构模式无疑是后者。

本篇就来谈谈目前我对几种客户端架构模式的粗浅理解,尤其适用于UI部分

首先一图以蔽之。

1. 事件监听和调用接口的区别。

A发送事件,B接收事件。A对B可以是无感知的,B的实现变了(例如换了一个库),A通常并不需要做什么改变(因为随着事件抛出的通常只是数据),即A和B无耦合。而A调用B的接口,就使得A必须劳神去照顾B的变化。这么一说好像调用接口不怎么优雅,但调接口真的很直接很方便! 另一个小区别就是,事件可以被多个监听者接收,这取决于项目中采用的消息机制。而调用接口嘛,虽然也可以(将所有被调用者的公共部分抽象成一个 interface,A去调用interface里对应的函数),但似乎麻烦了点。

2. 啥是 Model, View, 和X

粗暴地理解就是业务逻辑数据放在Model里,UI(文本、图片、动画、菜单啊)就是一个个View(或者subView),这两个东西一定要分开,不然代码量一多,就变成了一团毛球,极难维护。那 model 和 view 之间的联系由谁负责呢?由此,就产生了不同的框架模式。

3. MVP:你俩都是甩手掌柜

上面的图中,重点画出了三者的区别。首先说MVP。为什么叫P(Presenter)就不解释了,但可以发现,Model和View对外界都是无感知的,只需发出事件。所有的活儿交给P,P一面监听事件,一面调用下一步的接口——饭都喂到嘴边了啊。借用一些家庭主妇的口头禅就是:你们呢爷儿俩都是甩手掌柜!

4. MVC:我就上传不下达

MVC,三者形成了一个环。与MVP最大的不同是,MVC中的View包含了来自Model的事件处理逻辑,也就是View依赖于Model。C的任务就减轻了,只负责上传,以后的事情,你俩自己看着办。这是最经典的架构模式,

5. MVVM:在协议书上签字吧

MVVM,V为了分担一部分压力,与中间的View Model达成了一个“协议”,VM你按照这个协议将状态数据设置好,那么我就自动根据这些状态数据来改变自己的表现。这就叫双向绑定。实现方法:简单的如手写 get/set,然后有些现成的sdk可能基于get/set封装了一层api。还有的思路据说是不停地轮询,看状态有无变化。或者用观察者模式。 这样相比于MVP,好处是不至于“接口爆炸”,接口那么多,谁知道该用哪个!我们码农的记忆力也是有限的。

6. 个人看法

MVP将Model和View彻底解耦和了,而且容易理解,可能我还没悟到MVVM的双向绑定的妙处吧,但业内的共识是:双向绑定使得bug更难定位了。在写游戏UI的过程中,觉得MVP用起来比较自然,而且在这种思路下,可以进一步扩展,例如下图。图中Model之间也可能有事件监听的需要。

MVP-system

results matching ""

    No results matching ""