多年来，我总结出了一些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模块,或其它相同的模块
  

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

值得学习ing!