前言：设计模式的使用是为了使代码逻辑清晰，以一种大家普遍认可的思路组织代码结构，特定的模式可以解决特定的问题，同时也便于其他人阅读和维护。MVC是一种代码结构组织方式，涉及到多种设计模式，包括组合模式、策略模式、观察者模式。
说起MVC，似乎每个人都知道，MVC即Model、View、Controller(模型、视图、控制器)，大部分人应该也知道这个关系图：
但实际开发中是否真正利用到了MVC模式的精华之处，或者说是否真的知道MVC的精华之处。
我看过的大部分代码，包括我自己以前写的，结构基本就是View层是界面，Controller层是业务逻辑，Model层是数据结构这样的代码结构，而几乎所有的逻辑、数据操作、处理，UI模块的调用、事件响应都集中在Controller层（可以臃肿到好几百行）。
这样的结构唯一的优点就是什么都不用考虑，上来就是直接开干，不得不说Apple基本类的封装也是为程序员考虑，UIViewController、UIView、NSObject三者的结合使这样的代码结构也看起来似乎合情合理(说实话这种朴素的代码使用和阅读都挺方便的，所有代码都是直来直去)。
如果没有清晰的结构和各自独立的模块封装，在代码量大、结构和功能相对复杂、有功能需要调整的时候这种代码的维护就变得很麻烦了。你有没有过开发类似功能时要复制大量代码的经历？有没有自测时感觉无从下手？有没有在多个人开发一个功能时频频发生冲突？
MVC正是解决代码结构关系一种流行的方式，它和曾经也流行过的三层架构(UI层表示用户界面，BLL层表示业务逻辑，DAL层表示数据访问)极其相似，而大部分人也正是把MVC当做三层架构在使用和理解，如果是这样，那么你可能就错过了MVC的精华部分。
MVC设计的初衷是要将软件用户界面和业务逻辑分离以使代码可扩展性、可复用性、可维护性、灵活性加强。View层是界面，Model层是业务逻辑，Controller层用来调度View层和Model层，将用户界面和业务逻辑合理的组织在一起。
所以Controller中的内容应该尽量简洁，以提供View和Model最大的灵活性。各Model之间是可以相互调用的， Controller也可以无障碍的调用Model，因此将业务逻辑放在Model中可以灵活的使用组合的方式复用代码。
各层关系详解：
View—>Model —— view需要model的数据做显示
Model—>View —— model的数据改变时需要通知view
View—>Controller —— view发生某些事件时通知Controller，而Controller根据情况通知model
Controller—>View —— Controller作为载体加载view
Controller—>Mode —— Controller调用model的业务逻辑
比方说，有一个View会提交数据给Model进行处理以实现具体的行为，View通常不会直接提交数据给Model，它会先把数据提交给Controller，然后Controller再将数据转发给Model。
假如此时程序业务逻辑的处理方式有变化，那么只需要在Controller中将原来的Model换成新实现的Model就可以了(这当然还需要View合理的接口封装)，控制器的作用就是这么简单， 用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。
总结MVC的好处就是：耦合性低，视图层和业务层分离，重用性高，应用更易于维护、修改和单元测试。
但也不是没有缺点的：①在小型规模的项目中使用会显得杀鸡用牛刀而得不偿失；②视图与控制器间连接紧密，需要定义消息传递接口；③视图对模型数据的访问效率低，视图不直接调用模型而是使用接口，所以模型内部可能会有多余的操作或者数据未变化而频繁的访问。
