《茶余饭后小故事》MV*、MVC、MVP、MVVM的前世此生

今天咱们讲讲历史，讲讲故事，不扯高深术语。

MV*表示的意思是：M(Model逻辑层) + View(视图层) + *（中间者）。上帝提出了这个逻辑与视图分离，用中间者进行链接的伟大思想，并将实现这个思想的艰巨任务安排给人间。

人们纷纷跃跃欲试，想率先实现上帝布置的任务。随着历史的推移，不一样时期前后出现了三个著名的中间者，他们依次是Controler、Presenter、ViewModel。

Controler是第一个吃螃蟹的小伙子，昵称叫控制者。它与MV结合并自命名为MVC模式。它平生最大的贡献是能把视图层View的数据写进逻辑层Model,可是很惋惜，View不是经过它来读取Model的数据，而是跳过它，直接读取Model的数据。被“选择性无视”的Controler大失颜面，这件事也让它常常被后世取笑。

 

 

上帝很赞扬Controler的勇气，但看着MVC这上下都不对称的数据读写方式，感受有些啼笑皆非，显然对Controler不是很满意。

另一个叫Presenter的小伙站了出来，他身材健硕，力大无穷。只见他挺身而出地说：“我是Presenter,中文名叫主持人，之后视图层和逻辑层他们之间的通讯交给我来主持！”。

因而一个新的模式出现了---MVP模式。

 

这个模式看起来很是不错，在试行了一段时间后，上帝也感受很是满意，它不只对称，还隔离了Model和View，与前辈Controler那种半中间者不一样，Presenter是一个真正意义上彻底体的中间者！

但使人没有想到的是，好景不长，一段时间后Presenter忽然暴毙，死因：过分劳累。

人们开始反思MVP模式存在的问题，虽然它隔离了Model和View，可是Presenter老是须要手动去帮助Model和View完成通讯，是个“手动挡”，时间一长，Presenter里面的业务逻辑愈来愈重，终于有一天它不堪重负倒下了。

还能再选一个Presenter吗？显然不能，如此繁重的须要手动完成的活儿，选上去了就是等死啊，太累了，没人想干。

不过江山代有人才出，人类的智慧真是无穷无尽，有一天一个看起来弱不由风的小姑娘站了出来，她说道：“我叫ViewModel，也许我能够一试”。

民众纷纷瞪大了双眼，联想到强壮如牛的Presenter都死得这么惨，这个看起来弱不由风，身体几乎透明的小女子，能承担这样繁重的任务吗？

小女子说道：“我有三件法宝，分别唤做Angular，React和Vue，它们个个充满魔力，不须要手动来回处理View和Model之间的那些琐碎破事，它是自动完成的，用上它，大家甚至感受不到个人存在，我就是这么6，大道至简，一个真正完美的中间者可让人几乎忘却它的存在。”

民众一片哗然。

这，就是MVVM，它带来了一个全新的理念：自动双向绑定。

 

 

一时间，全民欢腾，上帝也大为满意，ViewModel的拥护者迅速增加，并迅速影响到全世界。

她是最好的中间者吗？不知道，至少从目前来看，她是。