一个app如果是一个人独自开发，那么你可以天马行空的编写代码，因为是你一个人完成其功能需求，并且进行后期维护，但是这样的app一般不存在，或者只存在于毕业论文中。但是在公司中都是多个人或者多个业务组维护一个app，这就决定着app需要有一个好的架构，拆分出各个业务模块，由不同的业务组维护自己的业务模块。并且架构合理的app对于后期维护、UI变动以及app中某些模块的复用提供了便利之处。
MVC作为经典的架构模式之一，虽然存在不足之处，但是很多app仍然使用该架构，那就说明MVC必有其存在的意义。
model--模型，统一管理各个对象模型，管理数据，有一定的复用性。
view--视图，视图的集合，用于展示控件，相关页面
controller--控制器，view和model的粘合剂，view和model通过控制器彼此间接交互。
一、苹果推荐的MVC模式
苹果推荐的MVC模式如上图，View和Model通过Controller协调。model通过通知机制通知Controller数据的变更，Controller更新View展示新的更新的数据；View接收用户的操作，通过target-action等机制通知Controller，controller通过更新model来响应用户的操作。一切都是如此的美好，但是事实却非如此。
一般，初级开发者接触到iOS开发后，经常将视图处理的逻辑放在ViewController中视图的生命周期函数中，没有所谓的单独的视图文件，将view和控制器合二为一了，使得控制器代码量剧增。另外，随着业务的复杂性的提升， service 服务可能在大多时间无法快速满足客户端需要的数据需求，移动端愈发的要自行处理一部分逻辑计算操作。一惯的做法是在控制器中处理，最终导致了控制器成了垃圾箱，越来越不可维护。导致了臃肿的控制器的出现。，推荐的MVC模式就逐渐的变成下面的模式了。这就导致了后期app维护的困难，编写测试用例的困难程度。
但是，只要我们在开发中合理的编写代码，合理的重构，MVC模式还是有很大的好处的，也不会导致臃肿的控制器。
二、苹果推奖的MVC模式详细介绍
iOS中的MVC（Model-View-Controller）将软件系统分为Model、View、Controller三部分

Model: 你的应app本质上是什么，它能实现的功能是什么，它持有数据。以登录业务来说，用户对象即为模型。
Controller：处理Model和View之间的交互，通过view将Model中的数据展示给用户；通过对model的更新来响应用户在View上的操作
View：用户可见的，一般是UIView的子类。用于UI控件的展示以及响应用户的操作。
Controller可以直接访问Model，也可以直接控制View。
但Model和View不能互相通信。
Model和Controller
Model不能直接访问Controller，Controller可以直接访问Model
Model不能直接与Controller通讯，因为Model是独立于UI存在的。但当Model发生改变想通知Controller时可使用广播机制，在iOS中有NSNotification和KVO（Key-value observing）可供使用。
View和Controller之间的交互机制
view不能直接访问controller，controller可以直接访问view
（1）View向Controller发送消息使用Target—action机制，当用户与app进行交互时，发生一些事件，比如滑动一个Slider（通过滑动Slider改变Label的值），滑动Slider后，对应的Slider的值就会改变，这时可能会给Lable重新赋值，这时候就需要Controller来完成UI的逻辑，使用Target来向controller发消息，触发action对应的方法
（2）有时候Controller需要实时监控View的状态，这时Controller会通过protocol将其自身设为View的delegate，它让View知道如果view想知道更多的信息，就要向Controller发送delegate消息（即遵循某个协议），这样当View will change、should change、did change 的时候Controller也会接到相应通知，做出相应的协调。
（3）View不存储数据，view通过datasource向Controller发送消息（data？、count？at？），进而获取Controller数据用来展示（Controller整理Model中的数据用于给View展示）。
推荐：唐巧大神的关于MVC的描述http://blog.devtang.com/2015/11/02/mvc-and-mvvm/