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模块,或其它相同的模块
永远不要设置或访问全局变量

　　模块

你应该使用一个模块系统，不管是CommonJS、AMD、ES6模块,或其它相同的模块
永远不要设置或访问全局变量

　　结语

　　本模式向导作为一份流动文档，在使用者遇到错误和获得经验的过程中不断完善。本文档的主要目的在于能让读者写出统一简洁的代码。如果您对本文档有任何建议，请联系@maccaw。

原文 blog.sourcing.io