MVC与MVVM

MVC

最基本的还是 MVC，MVC 的问题在于 C 过于庞大。在最初编写代码的时候一个 C 有时候要上千行。
传统 MVC 造成 C 庞大的原因：

• 使用 xib：使用 xib 将控件拖到 C 中，做一些 XIB 不方便做的属性操作，布局变化，动画、tableview 代理实现等。
• 网络：调用网络接口，对网络请求回数据进行包装处理。
• 数据本地化：请求后的数据调用数据库保存等业务。
• 逻辑：一些业务上的逻辑处理，排序、筛选或者相关关联性的业务逻辑处理。

解决方案：

• 代码实现 view：使用代码新建 view 完成 UI 部分，保证 C 中没有 view 层的操作，所有布局变化，动画，UI 控件调整，各个 view 的代理实现等都放在 view 中。
• 网络层：使用 YTKNetwork 第三方库进一步封装 AFNetworking。
• realm：使用 realm，新建相应模型与工具类，内部实现数据读写，只提供接口供外部调用。
• 业务层：使用相应 manager 在内部实现对网络层调用与数据库层接口调用，开放简单接口给 UI 层（C）。

这样 C 作为 UI 层的视图控制器，只进行简单的 view 加载，视图控制器间切换，调用业务层接口，将业务层 model 转化成 UI 层 model 赋值。
优点：网络层-业务层-UI 层-数据库，明确的层级划分，较好的解耦性，大项目开发中各自负责各自的模块，不会干涉开发进程（UI 图没出、接口没通、业务变动。。。）。
缺点：各自层有各自层的 model，代码重复，需要转换。（各自层有各自的 model，业务的 model 不关心 UI 展示，UI model 处理业务层 model 只关心自己要展示的，虽然代码量多了些，但是感觉挺好的，有啥问题继续反思。。也请大家赐教。。）

MVVM

MVVM 的出现是为了解决上述中 C 过于臃肿的情况。不同于把 C 中网络业务等完全抽出成新的层，MVVM 是划出 VM 来处理这些。
如果把上面 MVC 的优化看成是 MVC+Manager，那么 MVVM 实际上就是 VM 对应 Manager。

个人觉得 MVVM 的划分实际上是 VC - VM - M 这三个部分。
使用 MVVM 模式的话大多比较适合用 XIB（不用 xib 的话 c 其实没多大，没必要一定用 mvvm ），这样 view 和 controller 其实可以看做是一体，然后划分出 viewModel 来实现网络请求、业务逻辑处理、以及 model 封装，选择性把 vc 需要的属性从 model 中提取出来作为 vm 的属性暴露给 vc。
这样的话 model 可以尽量统一合并化，这样一个 vc 对应一个 vm（复杂页面的子 view 会 对应子 viewModel，但是总体还是一对一），但可能会多个 vm 对应一个 model。

MVVM+RAC

viewModel 作为 binder 夹在 vc 和 model 中间。Model 变化时，ViewModel会自动更新，而ViewModel变化时，View 也会自动变化，也就是双向绑定。
viewModel 暴露的永远是 model 属性封装好的信号。
更多内容还在学习中。