MVC 是一种设计模式， 它将应用划分为 3 个部分 ： 数据（ 模型）、 展现层（ 视图） 和用
户交互层（ 控制器）。 换句话说， 一个事件的发生是这样的过程 ：
1． 用户和应用产生交互。
2． 控制器的事件处理器被触发。
3． 控制器从模型中请求数据， 并将其交给视图。
4． 视图将数据呈现给用户。
现在来看一个真实的例子， 图 1-1 展示了在 Holla 中如何发送新的聊天消息。
从Holla中发送一个新的聊天消息
1． 用户提交一个新的聊天消息。
2． 控制器的事件处理器被触发。
3． 控制器创建了一个新的聊天模型（ Chat Model） 记录。
4． 然后控制器更新视图。
5． 用户在聊天窗口看到新的聊天消息。
我们可以不用类库或框架就实现这种 MVC 架构模式。 关键是要将 MVC 的每部分按照
职责进行划分， 将代码清晰地分割为若干部分， 并保持良好的解耦。 这样可以对每个部
分进行独立开发、 测试和维护。
下面来详细讲解 MVC 中的各个组成部分。
模型
模型用来存放应用的所有数据对象。 比如， 可能有一个 User 模型， 用以存放用户列表、
他们的属性及所有与模型有关的逻辑。
模型不必知晓视图和控制器的细节， 模型只需包含数据及直接和这些数据相关的逻辑。
任何事件处理代码、 视图模板， 以及那些和模型无关的逻辑都应当隔离在模型之外。 将
模型和视图的代码混在一起， 是违反 MVC 架构原则的。 模型是最应该从你的应用中解
耦出来的部分。
当控制器从服务器抓取数据或创建新的记录时， 它就将数据包装成模型实例。 也就是说，我们的数据是面向对象的（ object oriented）， 任何定义在这个数据模型上的函数或逻辑都可以直接被调用。
视图
视图层是呈现给用户的， 用户与之产生交互。 在 JavaScript 应用中， 视图大都是由
HTML、 CSS 和 JavaScript 模板组成的。 除了模板中简单的条件语句之外， 视图不应当
包含任何其他逻辑。
实际上， 和模型类似， 视图也应当从应用的其他部分中解耦出来。 视图不必知晓模型和
控制器中的细节， 它们是相互独立的。 将逻辑混入视图之中是编程的大忌。
这并不是说 MVC 不允许包含视觉呈现相关的逻辑， 只要这部分逻辑没有定义在视图之
内即可。 我们将视觉呈现逻辑归类为“ 视图助手”（ helper） ： 和视图有关的独立的小型
工具函数。