1 mvvm 学习

1.1 实现原理

mvvm 类框架的实现原理不复杂，大致如下：

• 模板分析得到依赖的属性
• 通过某种变动监测手段监测这些依赖的属性
• 当属性变动的时候，触发相应的 directive 的处理逻辑即可

实际上，directive 的处理逻辑不一定是对 view 进行操作，比如上报。但是，在 mv 的思想下，建议对 view 的操作都集中在 directive 里实现

从最核心上看，mv 思想仅仅是一个观察者模式的具体应用于延展而已

1.2 核心技术点

1.2.1 模板分析

模板分析是比较基础的，凡是和 view 相关的基本都会涉及模板，这是原始资料，这里的关键点是模板来源的问题，实际上，它应该可以是任何字符串

这里暗示了框架需要一个模板解析器，不管这个解析器复杂还是简单，它都处于一个模式：【输入 --> 模板引擎 --> 输出】

于是，mvvm 的模板解析器特点如下：

• 输入：任何符合规则的字符串
• 输出：需要监听的 data.attr，directive，filter

在设计一个框架的时候，如果想要有更好的可扩展性，则

输入应该足够灵活，从来源上来说，模板可以是 someDomHere.html()，也可以是动态输入，那就更有可适用性；从内容上来说，如果引擎可以识别更高级的语法，那就更有功能性

输出应该足够收敛，收敛的意思是有限并规则，像 mvvm 框架，最后出来的只是 directive 和 filter，具体的处理都集中在这两个概念中，仅扩展这两个概念，即可对系统进行扩展

1.2.2 变动监测

在众多 mvvm 类框架中，实现变动监测有 3 种：

1. 门面方法 setter，getter：比如 knockout，q。限定可以变动的入口，并且让入口使用权放给用户来决定。
2. 利用 defineProperty：比如 vue，avalon。本质上也是 setter，getter，但是没有把入口使用权放给用户来决定。
3. dirty check：比如 angular。对 angular 的研究够多了，这里也不赘述了。

1.2.3 小结与延伸

对一类复杂并且常见的问题进行分析，解耦，抽象，在实践的过程中获得广泛的认可，那就形成了一种模式，mvvm 也是一种模式，它不一定叫 mvvm 模式，这也不是笔者能决定的

对于这个模式的核心，笔者理解如下：系统根据配置得到了对某些数据源的某些处理规则，当数据源变动时就会引发相应的处理规则。模式的扩展是双向性，这由系统实现来决定，当符合某些规则的时候，可以对数据源进行更新。

我们跳出 view 的概念禁锢，联想实现一个监控系统，其实这个模式非常适合用在监控系统上面。

一般的监控系统的处理逻辑是：由收集源对监控数据进行收集整理，然后存储到数据库中，监控系统实时监控数据源，绘制实时的图线（反馈），当数据源发生了符合某些规则的变动时，就会触发相应的动作，比如报警。

如何实现这个系统，让系统具有更高的扩展性？参考 mvvm 模式，可以这样：

收集系统独立于监控系统，各不相同，暂且不论。监控系统通过某些配置文件取得需要监控的数据源与相应的处理逻辑规则，当数据源发生变动时触发相应的处理。

按照 mvvm 模式，进行一些抽象。

• 数据源不一定限定在数据库中，他可以在任何地方，只需要系统可以通过某些可配置的规则获取得到
• 处理规则进行抽象，让它更容易被扩展，比如发邮件，发短信，发微信，发 qq 消息等等

对应前端的 mvvm 框架，模板就是配置文件，directive 就是处理规则，data 对应数据源。

• 当系统需要新增一个数据源的时候，只需要更新配置文件，让系统读取即可启动数据监控
• 当需要新增一个处理规则的时候，可以通过一个热插拔的处理规则插件系统，扩展一个新的处理规则，再更新配置文件，系统即可接受新的处理规则

2 vue 实践

vue 介绍就不用了，太多资源了。这里讲述一下 vue 实践过程中的一些收获

2.1 组织结构