MVVM终结者（一）

一个MVVM的学习记录和感悟，我自己也在慢慢学习中，这个DEMO会慢慢完善并且会把学习中需要注意的东西记录下来。感谢关注阅读

首先先谈谈MVVM是个什么东西，以及为什么要使用MVVM

在刚接触IOS开发的时候，各种教科书上面都写着IOS是原生的MVC结构，先看一个典型的 iOS 是如何构建的：

Typical Model-View-Controller setup

依据上面的MVC构建IOS程序有着得天独厚的优势。因为

• 可以很方便的写出继承于NSObject类的Model
• 并且有针对View设计的UIView类
• 以及针对C设计的UIViewController类

但是仔细想一想，虽然IOS开发kit设计了三个看上去分离的类，但其实UIView和UIViewController往往是不分离的，UIViewController中原生就带着一个UIView的成员变量（也就是IOS应用程序中的每一个界面），所以说UIViewController其实更像是UIView的管理器，或者说UIViewController是封装了一层的UIView，所有的数据处理和逻辑全部就写在了UIViewController这个类中，就导致了逻辑其实已经和View绑在了一起，其实所谓的IOS中MVC其实是M（VC）两个部分构成，由于所有的view和业务逻辑都在这个类中，这样就导致了在UIViewController这个类不伦不类，代码混乱，在这个类中代码的量是非常多的，而且理想中的MVC中V和M这两个部分都是可以高度复用的，然而因为这里V和C粘在了一起就导致了这里的V也很难被复用（关于复用其实还设计到胖model和瘦model，这里我不做介绍，想了解清楚的自行google），基于

• 代码臃肿，逻辑混乱、分离
• 难复用

这两个就足以让代码强迫症患者无法忍受的缺点，不惜一切代价去改变。想让MVC真正的MVC起来、要做的就只是从VC中把逻辑给分离了出来，让（VC）只做一个纯粹的View，分离出去一个继承NSObject的逻辑类对象，M还是那个M。我觉的这才是真正的MVC也是IOS原本就应该有的样子。人们还给分离出去的逻辑类对象另外一个名字叫viewModel（VM），于是改进后的MVC就叫做M－V－VM。

在平常开发的过程中，VM需要告诉View该怎么展现自己，所以view初始化的时候一般要传入一个vm，也就是先有VM再有View，在view中持有一个VM的句柄，但是VM是不能拥有view的，所以这里的持有关系是单向的。view需要向用户动态展现在vm中的逻辑处理后不断变化的数据(自我更新)，同样用户所有对于view的操作过后的数据值流变化都要写入vm（自主写入），也就是说view现在变得特别的单纯，单纯的只认识VM一个人，view所有的行为都是在跟VM进行交互。但是view要显示的数据和数据的处理逻辑全部都是在VM中，而上面说到VM中是没有拥有view的，那在VM中逻辑处理完了以后，view自己是怎么实现更新自己的呢？这就要用到KVO来监听VM的变化了，幸运的是ReactiveCocoa（以下简称RAC）的出现，简化封装了大量这些操作、也彻底把MVVM搬上了IOS开发的大舞台。接下来的MVVM终结者后续篇是大篇幅的RAC教程