前言：
1.基本目的
将视图和数据分离开来，降低藕荷度
(1)Model : （数据模型，数据）持有并负责管理数据：封装，存储，处理数据运算等
(2)View : (视图，显示) 显示UI呈现给用户，对用户的target action 行为 有响应
(3)Controller ：（控制器，管理中心）调度程序工作，调解Model和View之间的交互 ，全部的表示逻辑、业务逻辑都在此 eg网络请求、事件响应方法
1）Model 和 View 永远不能相互通信，只能通过 Controller 传递。
2）Controller 可以直接与 Model 对话（读写调用 Model），Model 通过 Notification 和 KVO 机制与 Controller 间接通信。
3）Controller 可以直接与 View 对话，通过 outlet，直接操作 View，outlet 直接对应到 View 中的控件，View 通过 action 向 Controller 报告事件的发生(如用户 Touch 我了)。Controller 是 View 的直接数据源（数据很可能是 Controller 从 Model 中取得并经过加工了）。Controller 是 View 的代理（delegate)，以同步 View 与 Controller。
4.优点
（1）实现了基本目的：将视图和数据分离开来，降低藕荷度
(2) 方便debug调试问题出处是Controller还是View还是Model
5. 缺点
（1）随着项目的不断迭代开发，Controller 承担业务量加大，负担变重。因此网上提及MVVM好处时候不免都diss一下MVC是“Massive View Controller（重量级视图控制器）”
（2） 较差的可测试性
（3） 遗失的网络逻辑 //过重的Controller 被堆砌，很难从堆砌的网络逻辑中查找对应哪一个具体UI展示的
6.目前，我们做的尽可能给Controller 减负的方式
（1）遵循基本OC编码规则，明确函数分组和协议实现中使用#pragma mark -来分类方法。好处来说，代码结构清晰。不论厚重与否，我们都遵循统一编码规则，从review,迭代的角度，都是相对有利的
(2) 使用类别category，来管理控制器中的业务，一个业务一个同级别类别category。 例如首页元素：
- yiji和起居板块
- 健康档案计划
- 调理方案
- 症状
- 文章list
这些丰富的数据源来一个或者多个接口，UI展示出来有其特有的位置，于是选择使用类别category的方式来处理。
注意：使用类别只能离散化代码，逻辑层面更优秀一些，但不能真正减轻ViewController的负担。绝对依赖，还是有问题。进一步优化还是值得深挖挖
（3）分离数据源：实现 UITableViewDataSource 代理 协议相关的代码封装成一个类。这个我之前写过一个博客 参考链接2。
注意：这种方法最好是团队合作在开发上有交集，要绝对大家都知晓你这么做，并能认同这种优化方式，否则一个后果是，别人读不懂你的代码，同事又写了一遍。。。反而这种分离数据源的方法是一种过渡设计了
（4）使用一些优秀第三方减少代码量
eg. Masonry:在纯代码手动代码设置视图的约束时，优秀得无可挑剔
YYKit系列:真是业内大牛利用自己学习心得开源出来的，非常牛逼，阅读一遍源码，自己再进行开发时候都下笔如有神的感觉。
其中YYModel真是比自己写的那个反射好多了，足够面向对象，足够优秀,突然在大神面前感觉自己就是渣渣。继续努力，保持对学习进步的热忱之心
（5）尊重面相对象，该封装的方法，模块都进行封装。
eg.比如AFNetWorking ,做好封装。把相近业务网络请求部分放进一个类别里面，在控制器中直接调用我们自己的封装即可
(1)Model : 数据层 和MVC中model一样
(2)ViewController/View: 展示层 它包括了一些数据绑定，事件，和行为 和 UI展示给用户 （ViewController只做了部分胶水作用，View还是纯展示，触发事件响应给）
(3)ViewModel ：数据模型 封装业务逻辑，业务网络处理，封装数据缓存，即把MVC中 控制器中的以上三部分等放到ViewModel里面