“我是一个程序员，我听说过MVC设计模式，我知道什么是M什么是V什么是C，但为什么是MVC，而不是KVO，MMM或者其他的什么东西？我却说不出个所以然来。”是不是很多人都有这样的困惑呢？本篇博文就是解决这个问题。
回想一下，我开发的打地鼠游戏，花了2天写完了第一版。过了几天， 我觉得某个地方效果不太好，于是我把代码打开修补了一下。又过了几天，我又想了个新功能，加进去了。又过了几天，我又想了个新功能，加进去了。
很多产品都是这样，产品不停的往里面加功能，本来写的很好的东西，过了一段时间，却像一件破衣服一样，东一个补丁，西一个窟窿。代码改了这里忘了那里，引起了个新问题，甚至有的时候我们为了省事，走了捷径，结果回头忘了当时是怎么想的，然后代码越来越混乱，一团糟，直到你是作者你都不想去改它。甚至你都不敢改了，生怕改了这里忘了那里，又引起什么新的问题。
这还仅仅是个人项目，如果是团队几个人，他改了这里，我改了那里，如果不加协调，那后果不堪设想那。
但是人类是一种很神奇的动物，这种事情不会发生的。为了让代码变得更加可维护，可修改，灵活性更强，更加适应需求的变更，聪明的人们突破了传统思维的限制，发明了设计模式和设计原则。
MVC是个很复杂的东西，要真正的懂得MVC，我这一篇文章肯定是不够的，可能你需要买上几本大部头的书，好好啃一啃，如果你觉得你没看那么多资料，却已经懂得了MVC了，要么你是白痴，要么你是天才。不过我们没必要一下来就看懂什么是MVC，先来看点简单的，单例模式和命令模式。
最常见的设计模式：单例模式。
单例模式，就是在软件运行期间这个类有且只有1个对象。
为什么这么设计呢?一般单例模式的这个类的对象，需要在程序运行期间，有很多不同的地方调用它，但是又不能相互冲突。比方说播放声音的对象。所以我们就发明了一种方法，每次都叫这个对象来干这个活。
举个例子，我们宿舍有5个人，我们选出一位同学，他专职负责打水。如果我们发现暖瓶里面没有水了，我们就可以很简单的一句话：XXX去打水了。过一会，水就自动打过来了，我们不需要关心具体打水的过程。这里应用了命令模式。
下面开始正题：MVC设计模式
一开始，我们的软件只有1个部分，界面上直接写sql语句查询数据库，然后直接就显示出来。再来一个界面，再写一些sql语句，如果需要交互，那就写很多sql语句。比方说我们需要2个页面，一个页面显示饼图，一个页面显示柱状图，查询的数据都是一样的，很明显，这样的代码写起来的时候会有很多重复的东西。随着时间的推移，我们的软件越来越庞大，这个时候，我们发现我们之前设计的数据库有点小问题，需要改2个字段，然后所有涉及到的页面都要改。我们逐渐不堪重负，问题越来越多。
这时候，有必要把我们的软件划分为几个部分了。我们试图把我们的软件划分为2个部分，显示部分和处理部分。问题变得简单了，所有和界面显示相关的，都属于显示部分。所有和业务处理相关的，都属于处理部分。这样，我们就把写sql语句的工作，从界面上面剥离了下了，单独给它搞个地方，写成个函数，所有的界面直接调用这些函数。这样，界面的变动不会引起业务代码函数的变动，改起来更加方便了。
渐渐地，我们发现，仅仅是把软件分成2个部分，就降低了一层复杂度，如果分成更多的部分，是不是更好呢？于是人们发明了分成3个部分的MVC模式。
MVC试图把软件分成3个层，模型，视图，控制器，模型层处理软件里面的所有数据，而输入输出的部分，则交给视图层来显示，交给控制层来协调。
（控制器Controller）- 负责转发请求，对请求进行处理。
（视图View） - 界面设计人员进行图形界面设计。
（模型Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
但是开发的时候，总会有同学随意的编写代码，使我们分层的目的失效，为了更加规范点，达到我们之前的目的，我们定了一些规则。
模型层，可以不依赖控制器和视图独立存在的。模型操作数据，也就是说你的软件，所有的数据，都是由模型层来处理。
控制器可以主动向模型发消息。
控制器可以主动向视图发消息
视图和模型不能进行通信，想想看