MVC,MVP,MVVM到底怎么回事

MVC： model-view-controller

MVP： model-view-presenter 

MVVM：model-view-viewmodel

起初，世界上所有的电子设备本没有窗口界面。

后来，随着电子设备的普及，工程师们发现对于普通用户来说，电子设备的命令输入很难操作，需要记住很多命令，于是慢慢衍生出来UI这一说法。

可是对于程序员——或者说，对于软件工程开发而言，随着软件的体量增大，结构越来越复杂，单个程序的建设越来越困难。就好比以前是个小餐馆，几张餐桌，一个人厨师大堂经理服务员都兼任了。而现在，餐馆要同时面对数百位客人，一个人不可能既做饭，又结账，还要服务客人 。所以，有人研究出来了一种模式MVC。

MVC模式最初用于建筑行业，很久以前就有了，只是不叫这个名字，某位大神拿来之后，加以变化，研究出符合IT行业的MVC。从那时候，负责处理数据的代码，负责处理逻辑的代码，负责窗口显示的代码就分开了。他们各自做各自的事情，如果需要交互，那么通过设定好的暗号（接口/协议/数据流格式），进行给厨师提交客户的菜单，厨师召唤服务生传菜。服务生告诉大堂经理某个客人要结账。

MVC：（图片来自百度百科），大堂经理是Controller，服务生是View，厨师是Model

再到后来，软件的体量继续增大，我的意思是，餐馆变成酒店，厨师不止一个，服务生也不只一个，我们发现，厨师做好饭后，总是自己招呼服务生来传菜，但是厨师并不知道自己要招呼哪一个服务生，问服务生A，A说他要去给另一个厨师传菜；问B，B说他在收拾餐桌。所以，需要有个人来调度，那么，大堂经理他知道每一个人都在干什么，由他调度就好了嘛。所以至此衍生出来MVP模式。

MVP:(图片来自百度百科)

或许你会说：那这样可以叫改良版的MVC啊，为什么Controller改名叫Presenter了呢。第一：为了和MVC进行区分。虽然MVP是由MVC发展来的，但是世界上不可能每一家IT公司都会瞬间改变所有的产品架构，遗留的MVC的软件还是继续运行在这个世界的某些机器上。第二点，先记下，最后和MVP与MVVM一块说。

这样在某些方面， MVP拥有了替代MVC的必要性，但是这并不意味着发展至此结束。当软件的体量继续增大、人们对于模式的运用日渐纯熟，量变产生质变。

酒店进一步扩张，变成了五星级大酒店，人数一多，总不能什么事都由经理来调度，于是酒店决定，每一个厨师，配一个传菜员，只负责这个厨师的事情。

面对在这种 既定的、频繁的、有规律的，一对一的数据视图绑定，行业又提出一种模式，将Presenter的责任进行抽离，提取出 ViewModel，于是变成了下面这种。

MVVM:(图片来自百度百科)

View与Model进行绑定，在固定逻辑的基础上，由ViewModel进行数据的包装、拆解、验证和校对等职责。

或许你会说，这个ViewModel做的事情，Presenter也能做啊，为什么叫做这个名字了呢？

这个问题，和上一个让大家记下的问题，其实都可以这样解释：

并没有谁替代谁，面对不同的需求，我们总要进行一些改变，但是，这并不意味着，以前的东西就落后了，新的东西就是必然解决所有问题的万能灵药。

当然，有些缺点是显而易见的，MVC分离的M/V/C（要知道以前都是捏合在一起），使得软件工程真正称得上是“工程”——程序员们可以进行分工。久而久之，缺点也显现出来：Model的任何改变，都可以在View看的到，这样通过View，我们可以获得Model的信息。这是设计者们不愿意看到的。再比如,，MVVM下，ViewModel的出现使得程序员不用针对大量的view写特定的代码，但是，ViewModel里面必然不会存在大量的业务逻辑判断，这样不又要回归到MVP中去了吗。

很多时候，我们都是将各种模式用到一起，只是有的负责主体，有的在小的模块发挥其重要作用。讲这么多，也是希望读者可以不要盲目崇拜任何一种模式，模式都是用来解决某类场景下的问题的。今天是中国互联网诞生22周年，我还是个初学者，写的不好或者错了还请大家多多包涵，多多指教。