MVC
其实iOS的MVC感觉并不是经典的MVC模式，查阅很多的资料，经典的MVC是对于Web端来提出的，模型，视图，控制器之间都是单向传递数据引用，控制器只是负责业务逻辑。
而iOS中控制器本身也能够创建视图，同时视图必须添加到控制器中，UITableview就是很好的例子，这样控制器就不单单是业务逻辑的处理，它与View就像连体的兄弟，同穿一条裤子一样……
更像是MVP这样的模式，View与Presenter紧密相连… View 与 Model 不发生联系，都通过 Presenter 传递。View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里
…
直到看了一篇博文，引用了斯坦福大学公开课程中的一张图:
恍然大悟，这才是真正的iOS MVC 的正确理解(毕竟在xcode中是Controller)
大致的意思是
Controller可以和Model通信，也可以和View进行通信。而Controller和Model的关系，绿色的箭头代表Controller可以直接进行对Model进行访问，也就是说Model对于Controller来说就是透明的。如果Model发生了变化，那么就通过Notification和KVO的方式传递给Controller。同样的Controller和View之间也是这种关系，View对Controller来说就是 透明的。Controller可以直接根据Model决定View的展示。View如果接受响应事件则通过delegate，target-action，block等方式告诉Controller的状态变化。Controller进行业务的处理，然后再控制View的控制器中展示。
简单的说， 控制器不仅需要处理业务逻辑，视图的处理也在控制器中，同时还与数据模型交互 ，显然这样的处理方式会导致控制器臃肿，耦合度高，模块不易复用，同时代码的可读性降低，这样并不好，于是iOS的MVVM就诞生了
MVVM
与经典的MVVM也不相同，经典的MVVM是没有控制器的概念，只是数据的流向发生了改变， 它采用的是双向绑定，View的变动自动反映在VM(VM将指ViewModel)，反之亦然。
而iOS的MVVM中还有一个控制器，所以这样就是iOS特色MVVM
VM处理业务逻辑，Model与VM交互，VM与控制器交互，控制器与视图可以紧密相连。这样的写法可以看到，逻辑更加清晰，耦合度降低，模块复用性提高，编写测试也方便，控制器也进行了极大的减负，很棒！
但是缺点也是明显，每个控制器都需要VM，控制器与Model的交互变为控制器与VM交互，VM与Model的交互，代码量会增加，逻辑性需要更加的严谨，写起来也会慢一些，调试的话也会增加bug查找的难度
因为模块独立，所以两种设计模式(不是框架结构，架构是一个整体，涵盖项目方方面面)可以独立来写，控制器之间交互性低的地方，VM处理逻辑写法会简单些，可以考虑用MVVM，模块较为复杂控制器之间交互性强的地方，真的需要慢慢写了(之前想改个项目，主控制器逻辑太复杂，耦合性太高，不好剥离，最终只是写了请求部分逻辑剥离)
一点RAC与MVVM的理解
关于RAC
ReactiveCocoa(简称RAC),是GitHub上开源的一个应用于iOS和OS X开发的一个新框架.RAC具有函数式编程和响应者编程的特性.
一个完整RAC“流”的实现包括：创建信号，订阅信号，发送信号
RAC与MVVM配合能够减少代码，降低耦合性，以登录界面为例，按钮的状态通过RAC的观察者模式监听，能够放在VM中，数据的请求与处理可以放在VM中，这些业务逻辑都可以放在VM中。
而单纯的MVVM按钮的状态改变需要通过textfield代理监听传给VM处理，然后事件再回调判断，写法上比RAC复杂，而且数据请求中需要给控制器接口，RAC只需要控制器引用VM的raccommand信号类，RAC的raccommand本身拥有回调方法。
RAC很棒，但是RAC如果写的有问题，BUG将更加难以调试，所以要掌握很多的使用方法还需要不断地学习与实践，这里有整理好的一点关于RAC的使用，同时加上代码的注释，如果有需要，可以看一下