JavaScript的MVC模式向导

多年来，我总结出了一些MVC在Web应用中的规则。这些规则对我帮助很大，且避免了大型代码库陷入混乱。可能术语上不同，但这些规则对于诸如Backbone和Ember的大多数客户端MVC框架来说都是有用的。

一些框架在MVC的命名约定中有所不同，且在关注点的分离上也稍有不同。在这个文档中，controllers（控制层）是models（模型层）和views（视图层）的粘合剂，views（视图层）是HTML模板，models（模型层）仅单纯处理数据存储、检索和装饰。这与Backbone和Spine的术语基本相同。Ember有着类似的定义，不过在分离DOM访问控制层逻辑上更深入了一步。

控制层

• 控制层是模型层和视图层的粘合剂。处理大部分逻辑问题甚至管理问题。保持瘦控制器

• 任务父子控制器之间的通信均应使用事件（不要通过父控制器的实例来传递）

• 应该只知道其子控制器

• 应该限制单个元素，不要访问或修改DOM的其它部分

• 应该有唯一的类名且所有与控制器有关的CSS均应由这个类名来命名空间。

• 即使元素没有被附加到DOM树上，控制器也应该要工作。对于测试和验证控制器是否在正确的范围内，这个方法非常有效。

• 在对子元素发射事件时，应该是可测试的。

• 在没有不良反应的任何时候都应该有能力被重新调用

• 不要用DOM来存储状态——将所有视图的指定状态以实例属性的方式存储在控制器

视图层

• 除了流控制和辅助功能外，应该减少逻辑性

• 当需要直接渲染时，应该让所有数据都通过。在当前的域内，所有的数据都应该有效。

模型层

• 应该纯粹地与数据、操作数据和装饰数据关联

• 绝不访问控制层或视图层

• 绝对访问或返回DOM结点

• 在运行时，应该只能访问或请求其它的模型

• 应该将XHR连接与程序的其余部分抽象开来

• 应该包含所有数据验证

Router实例

• 尽可能的减少逻辑性

• 不应该知道或访问DOM

全局状态

• 你应该使用一个模块系统，不管是CommonJS、AMD、ES6模块,或其它相同的模块

• 永远不要设置或访问全局变量

模块