我创立的Model-View-Controller(MVC)模式作为一个直观的解决方案，针对的是一个一般性的问题，即让用户能够支配自己从多个角度看到的信息。MVC引起了的关注之多，让人有点始料不及。有些教材对MVC的改造甚至达到了离经叛道的程度，甚至企图达到让计算机来控制用户的悖谬目的。

    而MVC的根本目的是在人类头脑中的心智模型和计算机中的数字模型之间架起一座桥梁。理想情况下，MVC的实现方案与用户直接查看和操作领域信息的直觉吻合。假如用户想在不同的上下文中以及/或者以不同的视角看到相同的模型要素，那MVC就有了它的用武之地。

模型

    模型，表示知识。它既可能是一个对象(当然，如果仅一个对象就没多大意思了)，也可能是由许多对象组成的结构。

    模型及其组成部分是一方，而模型创建者意识中要表现的世界则是另一方，这两方应该一一对应。自然地，模型的每个节点都应该明确对应于问题的一个部分。

    模型的所有节点都应该把问题解决到相同的程度，把面向问题的节点(例如，在日程中添加约会活动)与实现细节(例如，用段落展示)混在一起不容易理解，是应该避免的做法。

视图

    视图是模型的(可见的)表现。视图通常会突出模型的某些属性，同时隐藏其他属性。从这个意义上讲，视图就像是一个展示过滤器。

    视图依赖于模型(或模型的一部分)，通过询问问题的方式从模型中获得用于展示的必要数据。视图通过发送适当的消息，也可以更新模型。这些问题和消息都要按照模型的术语来传达，由此视图必须得知道自己所要表现的模型，它的属性都有什么语义。(比如说，视图可能会询问模型的标识符，期待返回一个Text的实例，但它可能并不认为模型就是Text类。)

控制器

    控制器是用户与系统之间的纽带。它为用户提供输入，即它会将相关的视图显示在屏幕上适当的位置上(供用户浏览查看)。它为用户提供输出的手段，即它会向用户展示菜单以及其他能接受命令和数据的控件。控制器接收到上述的用户输出，将其转换为适当的消息，然后再将这些消息传递给一或多个视图。

    控制器不应该当作视图来用，例如，不能用控制器来画箭头以连接视图的节点。

    从另一方面讲，视图也不应该关心用户输入，比如鼠标操作或按键操作之类的。在任何情况下，都应该能够在控制器里编写一个方法，该方法将消息发送到视图，以便原原本本地再现用户的命令。

编辑器

    控制器负责连接其所有的视图，这些视图是该控制器的组成部分。有的视图会提供一个特殊的控制器，叫编辑器(editor)，以便用户通过它来修改由视图表现的信息。这种编辑器可以被挂接到控制器与其视图之间路径上，类似于控制器的扩展。编辑完成之后，则从路径上将编辑器移除并丢弃。

    注意，编辑器要通过相关视图的具体表现来与用户沟通，因此编辑器与视图是紧密相关的。控制器通过询问视图来获悉编辑器的存在，除此之外没有其他适当的信息来源。

建议继续学习：

1. 到底什么是MVC？    (阅读：9706)
2. 浅析C++多线程内存模型    (阅读：7113)
3. MVC演化史    (阅读：4430)
4. 亲爱的用户，您真的满意吗？    (阅读：4078)
5. Cassandra数据模型    (阅读：2800)
6. 【死磕Java并发】—–Java内存模型之happend-before    (阅读：2481)
7. Oracle数据库性能模型    (阅读：2280)
8. 信息架构中的常见模型    (阅读：2040)
9. 探讨：研发中心应该包括的核心元素模型    (阅读：1926)
10. 交互行为量化方法之GOMS击键层模型    (阅读：1796)