MVVM即Model（模型层）View（视图层）View Model（视图模型层）。
一、Model跟View不能直接通信，需要通过ViewModel，ViewModel充当了观察者的角色当Model发生变化时
二、ViewModel需要去监听变化同步给View将要发生的变化
三、ViewModel需要去监听用户对于View产生的变化同步给Model
对比MVC的改进
一、高内聚、低耦合
原本在MVC中，Controller承担了监听模型变化更新View，或者是监听View发生变化更新模型，这样在简单的页面中看似可行，但是在复杂的项目中这样干耦合度会非常高，违背了设计原则中高内聚、低耦合的原则，在复杂的项目中，对于程序的扩展以及维护的代价可想而知。但是在MVVM中，Controller只要处理基本的业务逻辑即可，相关的视图状态以及视图的模型更新都由View Model去处理，也不用去依赖对应的View以及Model，View Model实现了设计原则中的高内聚，而Controller实现了设计原则中的低耦合。
二、方便模块的复用
在传统的MVC设计模式中，比如我需要一个秒杀模块，或者拼团模块，如果只有单个App或者公司只有一个部门时，可以不需要复用，但是如果单个App中有多个页面需要用到秒杀模块，那么不同的VC中都需要去引入对应模块的模型以及视图，在遇到问题的时候模型和视图都需要去调整，如果采用MVVM方式，将秒杀模块封装成独立的模块，这样VC只需引用对应的View Model就可以了，向公司规模大的时候，比如我在京东金融的时候需要引入京东商城的模块，如果是采用传统的MVC模式开发的模块，那么迁移成本会非常巨大，先不说改变自身所导致可能发生的Bug，就光需要引入的后Controller对于该模块的逻辑处理是否全面，都需要开发人员仔细检查也难免保证不了跟原来的逻辑一致。所以采取MVVM方式最大的好处就是可以做到模块的App内服用，跨部门复用，甚至是提供给B端客户复用。
三、独立开发
传统MVC中，如果同一个VC都是多个开发人员去开发，那么每个人都需要创建VC需要的视图，然后创建模型，直接放到VC中，不同的开发人员都在VC中操作代码，这样做的弊端是1、容易产生提交代码的冲突 2、VC处理View逻辑时引发的其他模块的问题从而增加工作量。但是如果采取了MVVM的设计模式，就可以很有效的避免这样的情况，就像盖一栋楼一样，A B两个同学同时开发，B同学负责每个楼层的开发，A同学负责整栋楼的开发，最后B同学做好每层楼的开发，由A同学将这些楼层拼接在一起即可，京东金融的乐高组件就是基于这套原理，京东零售的CMS后台配置系统也是基于这套原理。
