JavaScript MVC 设计指南

近年来，我们通过使用MVC web框架来避免大规模代码陷入混乱，这让我们受益匪浅，同时在使用中我找出了了它们之间的一些共通规则。也许这些规则在框架中的术语有所不同，但是它们在大多数客户端MVC框架（如Backbone、Ember等）之间却是通用的。

框架之间会有不同的MVC命名约定，并会出于独立性的考虑做轻微的特殊处理。在本文中，控制器（controllers）是用来黏接模型和视图的，视图（views）指的是HTML模板而模型（models）则是纯粹的负责数据存取和包装等操作。这也与Backbone和Spine中的术语相契合。Ember有着类似的约定，唯一的区别是是它进一步的将DOM操作逻辑从控制器逻辑中抽离了出来。

控制器

• 控制器是视图和模型之间的黏接剂。它们的逻辑重点通常会在于事件管理。请保持控制器足够精简。
• 任何父级控制器和子控制器的通信都应该使用事件来传递（不要传递父级实例）
• 一个控制器应该只了解自己的子控制器（批注：意思是除了父子控制器之间，其他控制器之间不应该存在交集？）
• 每个控制器都应该局限于某个单个元素，它不能去访问或修改DOM中的其他元素
• 每个控制器都应该有一个独一无二的class名称，所有与该控制器相关的CSS都应该以它作为命名空间
• 每个控制器都应该可以在其对应的元素尚未插入到DOM树的时候也能正常工作。在测试和证明控制器很好的被局限的时候会很有益处
• 每个控制器都应该可以通过代码式的在他的子元素上面触发事件来被测试
• 每个控制器都应该可以在任意时间重新渲染并没有副作用
• 每个控制器都不应该使用DOM来存储状态——请将视图的特定状态存储为控制器的属性

视图

• 除了流程控制以及辅助功能外，视图不应该有其他的逻辑功能
• 应该被直接传递给它所需要用于渲染的所有数据。它在当前的整个作用域中都应该是可用的。

模型

• 它应该纯粹的只关心数据、操作数据和装饰数据
• 它应该永远不能访问到控制器或是视图
• 它应该永远都不能访问或者返回DOM节点
• 它在运行时中应该只能访问或者请求其他的模型
• 它应该负责将所有的XHR交互从应用中的其他部分抽象出来
• 它应该负责所有的数据校验

路由

• 它应该负责尽量少的逻辑
• 它不应该知道或是访问DOM

全局状态

• 它应该被保证被最小化，因为它可以说是与MVC的设计初衷背道而驰。不过想要获取类似于当前的用户、当前的视图或CSRF记号等食物，它却是唯一选择
• 它们不应该存储在全局变量下
• 它们应该被存储在一个独立的地方（比如说一个模型的单例实例）

模块

• 模块应该总是一个模块系统中的模块，不管这系统会是CommonJs、AMD、ES6还是类似的其他l类似的模块系统
• 永远不要设定或者访问全局变量

原文链接：http://blog.sourcing.io/mvc-style-guide