本文共 3605 字，大约阅读时间需要 12 分钟。
最近看到很多文章在谈论MVP或者MVVM模式的，但其实无论MVP还是MVVM都只是MVC模式的一种变种。而如果你对MVC的设计理念都还没有理解透彻，那么即使换成MVP亦或MVVM也不可能让你杂乱不堪的代码突然变得清晰明了起来，模式绝不是救命的稻草，它只是一种表现形式，真正要学的其蕴含的思维方式。
这是一个非新手都就会嗤之以鼻的问题，试问哪个程序猿不知道什么是MVC，但在此我希望大家先忘记之前对MVC的所有知识，很多时候学习的第一步就是承认自己的无知，这是一个多么重要的步骤，又是一个多么容易遗忘的步骤啊。包括我自己也是如此，经常因为固有思维而变得傲慢而不自知，今天我们就一起重头来学习一下MVC的历史。
对于MVC的概念我想没人不知，但是大部分人其实并不知道MVC的概念其实不止一个，从纵向来看，它经过了历史上很多的演进和变种；从横向来看，它也有许许多多不同的细微差异。即使包括后来的MVP和MVVM也都只能算它的一个变种而已。
大家坐稳了，老司机要带大家穿越时空回到1978年，来听听MVC模式的创始人挪威教授Trygve Reenskaug是怎么定义MVC模式的。
Models：
A Model is an active representation of an abstraction in the form of data in a computing system.
Views：
To any given Model there is attached one or more Views, each View being capable of showing one or more pictorial representations of the Model on the screen and on hardcopy. A View is also able to perform such operations upon the Model that is reasonabely associated with that View.
Controller：
A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on .to one or more of the views.
A controller should never supplement the views, it should for example never connect the views of nodes by drawing arrows between them.
Conversely, a view should never know about user input, such as mouse operations and keystrokes. It should always be possible to write a method in a controller that sends messages to views which exactly reproduce any sequence of user commands.
有兴趣的同学可以去阅读完整的论文 。
这是最早期的MVC模式，其中三者的定义可以简单的理解为：
注意先不要喷，在早期的MVC模式中，Controller的设计目的其实并不是为了隔离Model和View的，而后来这点才发现了变化。
Model和View的关系，也可以分为两种形式：
但不管是那种模式，model对于view都是没有感知的，push model是在数据变化的时候简单的发送广播，告之所有对该数据变化感兴趣的监听者，而pull model是view对model进行调用。因此在任何一种模式下，model都是不能直接操作view。
这种model-view模式也就是俗称的观察者模式，model是被观察者，view是观察者，当被观察者发送变化的时候，通知注册在它上面的所有观察者。这样设计带来的另一个好处就在于多个view可以监听同一个model的变化。
关于Controller和View的关系，Controller是绑定在View上面的，意思是用户任何在View上的操作（例如点击按钮等）都会调用Controller上的一个回调方法。其实也意味着View是持有Controller的引用的，当用户做相应操作时，是由View来调用合适的Controller方法的，而Controller对View的操作在早期概念中则不太明确。
Controller是可以向Model直接通信的。例如用户点击了删除按钮，那么Controller将用户的这个操作翻译成“用户需要删除这条数据”的消息传递给Model，Model负责删除数据，然后通知View来更新页面以告知用户数据的变化。
与经典MVC模式不同，很多现代系统设计中，如Apple Cocoa框架，最大的改变在于将Controller的位置放在了Model和View之间。
主要区别就在于Controller的位置变了：Controller将消息传递给Model，M处理完数据后是先将数据的变化通知给C，再由C来通知View来变化视图的。也就是说Controller变成了在Model和View之间双向传递数据的中间协调者，关系变成了： View <-> Controller <-> Model 。
Model和View之间没有了任何关系，所有通信都是通过Controller传递。
View通过Controller向model传递用户操作的消息，而model在处理完数据后通过Controller来向View来传递结果。Controller从经典MVC模式中的单向翻译官变成了双向的中间人。
其实大家都看出来了，这样变的主要目的就是为了让Model和View之间不再直接联系。从而使得三者的关系理得更清楚了。
了解MVP概念的同学可能读到这里可以会产生巨大的问号：这货不就是MVP吗？MVP里面的Presenter不就是充当Controller和View之间的中间人吗？
可以说Apple Cocoa这类框架使用的这种进化版的MVC确实离MVP相差很小了，可以说只差一步而已，MVP只是把三者之间的关系解藕得更厉害而已。
不管是传统的MVC，还是进化的MVC，亦或者MVP和MVVM模式，你会发现其实它们的设计理念都是一致的，逐步进化也只是为了更进一步的达到这个理念的目标，那就是：
上帝的归上帝，凯撒的归凯撒！
如果你没有理解这一点，那么用什么模式也是混乱的；而如果你理解了这一点，什么模式不用也是清晰的。