很多客户端研发一直在使用苹果推荐的MVC架构模式。MVC从应用层面进行分层开发，极大优化了我们的代码结构，简单易上手，很容易被程序员所接受。程序员刚接手一个新项目，如果是MVC的架构模式，会减少代码熟悉时间，快速的进行开发和维护工作，实际上对于多人开发维护的项目，MVC仍然是非常好的架构模式，这也是这种架构模式经久不衰的原因。
但是任何事物都有两面性，随着项目需求的增加，业务逻辑、网络请求、代理方法等都往Controller层加塞，导致Controller层变得越来越臃肿，动辄上千行的代码量绝对是维护人员的噩梦，因此在MVC基础上逐渐衍生出来了MVP、MVVM等架构模式。具体在业务开发中使用哪种模式需要你自己去衡量。
传统的MVC设计模式
M: Model 数据层，负责网络数据的处理，数据持久化存储和读取等工作V: View 视图层，负责呈现从数据层传递的数据渲染工作，以及与用户的交互工作C: Controller控制器，负责连接Model层跟View层，响应View的事件和作为View的代理，以及界面跳转和生命周期的处理等任务
用户的交互逻辑
用户点击 View(视图) –> 视图响应事件 –>通过代理传递事件到Controller–>发起网络请求更新Model—>Model处理完数据–>代理或通知给Controller–>改变视图样式–>完成
可以看到Controller强引用View与Model，而View与Model是分离的，所以就可以保证Model和View的可测试性和复用性，但是Controller不行，因为Controller是Model和View的中介，所以不能复用，或者说很难复用。
上面的内容中，已经详细描述了model、view和controller之间如何各司其职(即该是谁的东西，谁就要保护好，不能让另外一个越俎代庖的去处理)。MVC模式虽然是iOS编程中使用最广泛的模式，但论起复杂程度，MVC模式可以算是众多设计模式之首。通常情况下，MVC模式需要综合使用target-action模式、delegate模式、Notification或KVO模式等。下图是斯坦福大学的iOS一堂关于iOS介绍的公开课上所使用的示例图，这张图像也生动的描绘出来了MVC模式的工作原理，接下来的原理讲解也是依托于这张图像：
1、 Controller和View之间可以通信，Controllor通过outlet(输出口)控制View，View可以通过target-action、delegate或者data source(想想UITableVeiwDatasource)来和Controller通信；
2、 Controller在接收到View传过来的交互事件(View就是完成让人和程序的交互的呀，比如按B1按钮)之后，经过一些判断和处理，把需要Model处理的事件递交给Model处理(比如刚才的例子中的保存到数据库)，Controller对Model使用的是API；
3、 Model在处理完数据之后，如果有需要，会通过Notification或者KVO的方式告知Controller，事件已经处理完，Controller再经过判断和处理之后，考虑下一步要怎么办(是默默无闻的在后台操作，还是需要更新View，这得看Controller的“脸色”行事)。这里的无线天线很有意思，Model只负责发送通知，具体谁接收这个通知并处理它，Model并不关心，这一点非常重要，是理解Notification模式的关键。
4、 Model和View之间不直接通信！
按照上面的原理，我们知道了M、V、C之间的各司其职——Model不保存控件，View不做数据库操作(但这个也不是绝对，如果需要View做一些数据缓存工作，还是需要保存一些临时数据的)，而Controller就充当了两者之间的协调器。
参考例如：https://www.jianshu.com/p/4b94de458c0d?utm_source=desktop&utm_medium=timeline