在看mvc和mvvm的区别之前咱们来看一下前端的倒退历史

在上个世纪的1989年，欧洲核子研究中心的物理学家Tim Berners-Lee创造了超文本标记语言（HyperText Markup Language），简称HTML，并在1993年成为互联网草案。从此，互联网开始迅速商业化，诞生了一大批商业网站。

最早的HTML页面是齐全动态的网页，它们是事后编写好的寄存在Web服务器上的html文件。浏览器申请某个URL时，Web服务器把对应的html文件扔给浏览器，就能够显示html文件的内容了。

如果要针对不同的用户显示不同的页面，显然不可能给成千上万的用户筹备好成千上万的不同的html文件，所以，服务器就须要针对不同的用户，动静生成不同的html文件。一个最间接的想法就是利用C、C++这些编程语言，间接向浏览器输入拼接后的字符串。这种技术被称为CGI：Common Gateway Interface。

很显然，像新浪首页这样的简单的HTML是不可能通过拼字符串失去的。于是，人们又发现，其实拼字符串的时候，大多数字符串都是HTML片段，是不变的，变动的只有多数和用户相干的数据，所以，又呈现了新的创立动静HTML的形式：ASP、JSP和PHP——别离由微软、SUN和开源社区开发。

在ASP中，一个asp文件就是一个HTML，然而，须要替换的变量用非凡的<%=var%>标记进去了，再配合循环、条件判断，创立动静HTML就比CGI要容易得多。

然而，一旦浏览器显示了一个HTML页面，要更新页面内容，惟一的办法就是从新向服务器获取一份新的HTML内容。如果浏览器想要本人批改HTML页面的内容，就须要等到1995年年底，JavaScript被引入到浏览器。

有了JavaScript后，浏览器就能够运行JavaScript，而后，对页面进行一些批改。JavaScript还能够通过批改HTML的DOM构造和CSS来实现一些动画成果，而这些性能没法通过服务器实现，必须在浏览器实现。

用JavaScript在浏览器中操作HTML，经验了若干倒退阶段：
第一阶段，间接用JavaScript操作DOM节点，应用浏览器提供的原生API：
第二阶段，因为原生API不好用，还要思考浏览器兼容性，jQuery横空出世，以简洁的API迅速俘获了前端开发者的芳心：
第三阶段，MVC模式，须要服务器端配合，JavaScript能够在前端批改服务器渲染后的数据。
当初，随着前端页面越来越简单，用户对于交互性要求也越来越高，想要写出Gmail这样的页面，仅仅用jQuery是远远不够的。MVVM模型应运而生。

MVVM最早由微软提出来，它借鉴了桌面应用程序的MVC思维，在前端页面中，把Model用纯JavaScript对象示意，View负责显示，两者做到了最大限度的拆散。

2.当初让咱们从MVC开始

简直所有的App都只干这么一件事：将数据展现给用户看，并解决用户对界面的操作。
MVC的思维：一句话形容就是Controller负责将Model的数据用View显示进去，换句话说就是在Controller外面把Model的数据赋值给View，比方在controller中写document.getElementById("box").innerHTML = data[”title”]，只是还没有刻意建一个Model类进去而已。

M、V、C

Model（模型）：是应用程序中用于解决应用程序数据逻辑的局部。
　　　　通常模型对象负责在数据库中存取数据。

比方咱们人类有一双手，一双眼睛，一个脑袋，没有尾巴，这就是模型，Model定义了这个模块的数据模型。在代码中体现为数据管理者，Model负责对数据进行获取及寄存。数据不可能凭空生成的，要么是从服务器下面获取到的数据，要么是本地数据库中的数据，也有可能是用户在UI上填写的表单行将上传到服务器下面寄存，所以须要有数据起源。既然Model是数据管理者，则天然由它来负责获取数据。Controller不须要关怀Model是如何拿到数据的，只管调用就行了。数据寄存的中央是在Model，而应用数据的中央是在Controller，所以Model应该提供接口供controller拜访其寄存的数据（通常通过.h外面的只读属性）

View（视图）：是应用程序中解决数据显示的局部。
　　　　通常视图是根据模型数据创立的。

View，视图，简略来说，就是咱们在界面上看见的所有。它们有一部分是咱们UI定死的，也就是不会依据数据来更新显示的，比方一些Logo图片啊，这里有个按钮啊，那里有个输入框啊，一些显示特定内容的label啊等等；有一部分是会依据数据来显示内容的，比方tableView来显示好友列表啊，这个tableView的显示内容必定是依据数据来显示的。咱们应用MVC解决问题的时候，通常是解决这些依据数据来显示内容的视图。

Controller（控制器）：是应用程序中解决用户交互的局部。
　　　　通常控制器负责从视图读取数据，管制用户输出，并向模型发送数据。

Controller是MVC中的数据和视图的协调者，也就是在Controller外面把Model的数据赋值给View来显示（或者是View接管用户输出的数据而后由Controller把这些数据传给Model来保留到本地或者上传到服务器）。
综合以上内容，实际上你应该能够通过面向对象的根本思维来推导出controller呈现的起因：咱们所有的App都是界面和数据的交互，所以须要类来进行界面的绘制，于是呈现了View，须要类来治理数据于是呈现了Model。咱们设计的View应该能显示任意的内容比方页面中显示的文字应该是任意的而不只是某个特定Model的内容，所以咱们不应该在View的实现中去写和Model相干的任何代码，如果这样做了，那么View的可扩展性就相当低了。而Model只是负责解决数据的，它基本不晓得数据到时候会拿去干啥，可能拿去作为算法噼里啪啦去了，可能拿去显示给用户了，它既然无奈接管用户的交互，它就不应该去管和视图相干的任何信息，所以Model中不应该写任何View相干代码。然而咱们的数据和界面应该同步，也就是肯定要有个中央要把Model的数据赋值给View，而Model外部和View的外部都不可能去写这样的代码，所以只能新发明一个类进去了，取名为Controller。

3.上面来看这张图

斯坦福大学公开课上的这幅图来阐明，这能够说是最经典和最标准的MVC规范

mvc.png

这张图把MVC分为三个独立的区域，并且两头用了一些线来隔开。很有意思的设计，因为这些线仿佛呈现在了驾校科目一的内容中，你瞧C和V以及C和M之间的白线，一部分是虚线一部分是实线对吧，这就表明了援用关系：C能够间接援用V和M，而V和M不能间接援用C，至多你不能显式的在V和M的代码中去写和C相干的任何代码，而V和M之间则是双黄线，没错，它们俩谁也不能引用谁，你既不能在M外面写V，也不能在V外面写M。哦，下面的形容有点小小的问题，你不是“不能”这样写，而是“不应该”这样写，没人能阻止你在写代码的时候在一个M外面去写V，然而一旦你这样做了，那么你就违反了MVC的标准，你就不是在应用MVC了，所以这算是MVC的一个必要条件：应用MVC –> M外面没有V的代码。所以M外面没有V的代码就是应用MVC的必要条件。

View和Controller的交互

按钮点击事件，是View来接管的，然而解决这个事件的应该是Controller，所以View把这个事件传递给了Controller，如何传递的呢，见图，看到View下面的action没有，这就是事件，看到Controller下面的target没有，这就是靶子，View到底要把事件传递给谁，它被规定了传递给靶子，Controller实际上就是靶子。只是View只负责传递事件，不负责关怀靶子是谁。就像你是一个负责运货的少年，你惟一晓得的是你要把货（action）交给上头（开发者）通知你的那个收货的人（target），至于那个收货的人是警察还是怪兽，你都不须要关怀。这是V和C的一种交互方式，叫做target-action。所以你看，这张图几乎就是神来之笔，旁边还栩栩如生的画出了V对C的另一种传值：协定-委托。委托有两种：代理和数据源。什么是代理，就是专门解决should、will、did事件的委托，什么是数据源，就是专门解决data、count等等的委托。

Model和Controller的交互

M是干嘛的？下面说了，M就是数据管理者，你能够了解为它间接和数据库打交道。这里的数据库可能是本地的，也可能是服务器上的，M会从数据库获取数据，也可能把数据上传给数据库。M也将提供属性或者接口来供C拜访其持有的数据。咱们就拿一个简略的需要作为例子，如果我想在一个模块中显示一段文字，这段文字是从网上获取下来的。

那么应用MVC的话，在C中必定须要一个UILabel（V）作为属性来显示这段文字，而这段文字由谁来获取呢，必定是由M来获取了。而获取的中央在哪里呢？通常在C的生命周期外面，所以往往是在C的一个生命周期办法比方viewDidLoad外面调用M获取数据的办法来获取数据。当初问题来了，M获取数据的办法是异步的网络申请，网络申请完结后，C才应该用申请下来的数据从新赋值给V，当初的问题是，C如何晓得网络申请完结了？

这里咱们肯定要换一种角度去思考，咱们进一步思考M和V之间的关系：它们应该是一种同步的关系，也就是，不论任何时刻，只有M的值产生扭转，V的显示就应该产生扭转（显示最新的M的内容）。所以咱们能够关注M的值扭转，而不必关怀M的网络申请是否完结了。实际上C基本不晓得M从哪去拿的数据，C的责任是负责把M最新的数据赋值给V。所以C应该关注的事件是：M的值是否产生了变动。

4.MVVM

MVVM的诞生

就像咱们之前剖析MVC是如何正当调配工作的一样，咱们须要数据所以有了M，咱们须要界面所以有了V，而咱们须要找一个中央把M赋值给V来显示，所以有了C，然而咱们疏忽了一个很重要的操作：数据解析。在MVC出世的年代，手机APP的数据往往都比较简单，没有当初那么简单，所以那时的数据解析很可能一步就解决了，所以既然有这样一个问题要解决，而面向对象的思维就是用类和对象来解决问题，显然V和M早就被定义死了，它们都不应该解决“解析数据”的问题，理所应当的，“解析数据”这个问题就交给C来实现了。而当初的手机App性能越来越简单，数据结构也越来越简单，所以数据解析也就没那么简略了。如果咱们持续依照MVC的设计思路，将数据解析的局部放到了Controller外面，那么Controller就将变得相当臃肿。还有相当重要的一点：Controller被设计进去并不是解决数据解析的。1、治理本人的生命周期；2、解决Controller之间的跳转；3、实现Controller容器。这外面基本没有“数据解析”这一项，所以显然，数据解析也不应该由Controller来实现。那么咱们的MVC中，M、V、C都不应该解决数据解析，那么由谁来呢？这个问题实际上在面向对象的时候相当好答复：既然目前没有类可能解决这个问题，那么就创立一个新的类进去解决不就好了？所以咱们聪慧的开发者们就专门为数据解析创立出了一个新的类：ViewModel。这就是MVVM的诞生。

如何实现MVVM

搞清楚了MVVM为什么会呈现，将对于你了解如何实现MVVM有极大的帮忙。在咱们开始着手实现MVVM之前，我先简略提一下之前遗留的一个问题：为什么MVVM这个名字外面，没有Controller的呈现（为什么不叫MVCVM，C去哪了）。原本这个问题应该在实现后再来解释，然而咱们这里是教学，为了让大家更好的明确咱们接下来的思维，所以这里要提前解释一下这个论断：Controller的存在感被齐全的升高了。咱们在待会实现MVVM的时候你就能领会到了，这里请先把这个论断印在脑海当中：Controller的存在感被齐全的升高了、Controller的存在感被齐全的升高了、Controller的存在感被齐全的升高了。

好的，咱们终于要开始着手实现MVVM了。如果你曾经搞懂了MVC，那么用MVVM实现一个雷同的性能将会变得非常简单。你只须要记住两点：1、Controller的存在感被齐全的升高了；2、VM的呈现就是Controller存在感升高的起因。

Controller存在感升高的起因

在MVVM中，Controller不再像MVC那样间接持有Model了。设想Controller是一个Boss，数据是一堆文件（Model），如果当初是MVC，那么数据解析（比方整顿文件）须要由Boss亲自实现，然而实际上Boss须要的仅仅是整顿好的文件而不是那一堆乌七八糟的整顿前的文件。所以Boss招聘了一个秘书，当初Boss就不再须要治理原始数据（整顿之前的文件）了，他只须要去找秘书：你帮我把文件整顿好后给我。那么这个秘书就首先去拿到文件（原始数据），而后进行整顿（数据解析），接下来把整顿的后果给Boss。所以秘书就是VM了，并且Controller（Boss）当初只须要间接持有VM而不须要再持有M了。如果再进一步了解C、VM、M之间的关系：因为Controller只须要数据解析的后果而不关怀过程，所以就相当于VM把“如何解析Model”给封装起来了，C甚至基本就不须要晓得M的存在就能把工作做好，前提它须要持有一个VM。那么咱们MVVM中的持有关系就是：C持有VM，VM持有M。这里有一个比拟争议的中央：C该不该持有M。我的答案是不该。为什么呢，因为C持有M没有任何意义。就算C间接拿到了M的数据，它还是要去让VM进行数据解析，而数据解析就须要M，那么间接让VM持有M而C间接持有VM就足够了。最初再分享一个我在实现MVVM中的一个技巧，也谈不上是技巧吧，算是一种必要的思维：一旦在实现Controller的过程中遇到任何跟Model（或者数据）相干的问题，就找VM要答案。这个思维待会咱们会在实现代码的时候用到。