MVC、MVP、MVVM的特点和关系

一.mvc
首先简单介绍一下
MVC全名是Model View Controller。
是模型(model)－视图(view)－控制器(controller)的缩写。
模型：就是一组有关系的数据。一般是一个类。
视图：表这组关系数据表示出来的容器。一般就是能显示上面数据的一组控件。
控制器：就是用户响应的接口，一般相当于一个函数。
他们三个完成工作的一般过程是这样的。
1.用户发生一个命令，这个命令道发给控制器。
2.控制器干啥，目标很明确，就是使模型有数据，把用户要的数据模型构建出来；数据模型创建完了，通知view
3.view收到通知后，把数据表示出来。用户看到页面。
用户对软件一般两种目的，我要干啥，不一定要页面。
很多时候都都是我要看啥？
我要看啥的时候，看啥呢，就是view。
这时候mvc就上场了。
mvc的模型为什么这么普及，做过开发的人都知道，大部分程序都离不开画面（view）。离不开数据（model）。离不开控制数据(controller)。
所以很多程序都被这么天然的做了一个切分。
MVC的价值不多说了，因为我们面临的很多问题都拥有这3个面。
那么为什么还产生了那么多的其他设计模型呢，mvp，mvvm。
这就涉及到3个元素中更稳定的元素了。更稳定的是啥，m和v。模型和视图。
为什么使这两个呢。因为这很多时候用户的目的，用户要看到的东西用什么表现，必须是视图。
表现视图的内容是什么，是数据，也就是模型。
那么不可能用户想要什么页面，就有什么页面，用户再浏览页面至少还有一个切换的过程。
那么就还有两件事，响应用户的要求，按照用户的要求加工页面。
这个响应和加工的过程，就涉及到很多种方式。
数据加工完了，怎么给页面？是页面自己去取，还是控制器取给你取？
还有数据变化的时候怎么通知页面？
对上面这三个问题的不同出来方式，实际上就涉及了，两种不同的模式。
如果数据模型加工完了，数据模型通知视图，我准备好了，你来取数据把。这种模式就是mvc。
这时候为什么叫mvc呢？因为controller做的事情就是一个控制，把用户的命令传递下去，他就相当于一个控制器的作用。
二.mvp
而如果数据加工完了，数据模型通知控制器，我加工完了，你来取吧。控制器把数据取回来，把数据设置给view，这就是所谓的mvp模式。
到这里您可能会问，数据模型加工完了，要给视图，就让他俩自己处理就得了呗。管你控制器什么事？
还真是这么个道理，但是mvc至少有一个缺点。1.测试困难，c->m->不可分割，不能单独测试。
下面先说说mvp吧，总之mvp是由些有点的。
控制器的事情多了，也就是权限变大了。他成了一个组织者了。
相当于他们三个的小组长了。带来的好长，其实和在3个人中选拔一个下组长的价值差不多。
我看你们三个干的怎么样，直接就问小组长（小组长这时候的正式名称叫主持人）。
我看看控制的怎么样，发个命令给小组长，数据加工完了，一看数据没有问题。期待的数据是正确的，没有问题，证明由命令道数据这一段没问题。
在看看表示的什么样，这时候数据模型说，我这还没准备好。主持人说：没关系，我给页面一些数据，看是不是现实我期待的结果就知道了。一看数据也没有问题。
说到这里，其实mvp的最大价值就是，可以分布测试，单独测试数据和单独测试表示。
如果是mvc模式呢，因为由控制到模型到视图是关联一起的，单独测试比较困难。
MVP（Model-View-Presenter）是MVC的改良模式。
三.MVVM
MVVM( Model-View-ViewModel ）是MVP的改良版，具体就是Presenter的权利又大了，给他配个助理（Binder）。
这又是为啥呢？这时候模型和视图之间只要一方有变化，另一方就自动的同步。具体实际是在前面的需求上增加一个条件。
以前是数据变化了，要通知视图。没有视图变化的时候，现在加上视图也会变，比如表单的输入什么呢。
现在实际上是需求变花了，以前用户点击一个按钮，控制器响应，加工模型，通知视图表示，无论控制器还是模型去通知。通知完了结束了。
这时候加了一个什么动作呢，现实的视图是可交互，且这交互仍然由刚才的那个控制器去响应，再处理一遍。这实际上多了一次控制。页面在发命令，数据在响应。且可能这种视图变影响数据变，数据变影响视图变，可能在这个模型中存在多次。
所以这里应该是一个模式使用范围的扩大，并不是简单的升级，现在都4个人来干了。