框架模式：MVC、MVP、MVVM、MVPVM
一、前言
早期开发没有任何概念，主要以实现需求为主，没有视图、没有模型、也没有控制器一说，功能逻辑和UI展示都杂糅在一起。
1970年，TrygveReenskaug在SmallTalk-80系统上首次提出了『MVCE』概念（Model-View-Controller-Editor），后来去掉了『E』，这就是『MVC』的起源，那时的程序设计不像现在，还是GUI程序设计。
1996年的一篇论文，提出了MVC演化为了MVP；
2005年，微软架构师"John Gossman"推出了MVVM；
而我（当然网上也有），只是更进一步的优化MVVM而衍生出了MVPVM；
GOF将MVC看做是3种设计模式的合体：《观察者模式》、《策略模式》、《组合模式》；核心是《观察者模式》。
对于框架而言，我们可以理解为框架面向一系列相同行为的代码的重用
对于设计而言，我们可以理解为面向一系列相同结构代码的重用
二、MVC
MVC.png
我们可以看到，Model、View、Controller三者杂糅在一起，彼此可以相互调用，耦合度非常高。
优点：
- 上手快，学习成本低；
- 开发快，效率高；
缺点：
- 代码耦合严重（一处改动可能影响整个功能逻辑），难以重用，维护成本高；
- 代码臃肿，可读性随业务复杂度上升而变差；
- 难以测试；
三、MVP
MVP.png
MVP是基于MVC演化而来，主要目的是降低耦合度，让各层职责单一，同时也能够方便测试。
优点：
- View只负责显示，以及人机界面交互，以及View的状态（如输入，单选多选等状态）；
- Presenter层负责逻辑处理，更新Model，通知View刷新；
- 重用代码和模型；
- Mock数据，或者方便单元测试；
缺点：
- 文件/类较多，需要良好的目录组织结构；
- Presenter可能会变的笨重，相对维护成本会高；
- IView接口庞大（set / get操作）;
四、MVVM
MVVM.png
咋一看，与MVP没啥区别，区别主要还是在职责上。
Model职责不变；View被化分成了两部分：1. 展示与交互；2. View的状态（即输入数据）转移至ViewModel中；因此View不再需要与Model绑定，而是与ViewModel绑定；ViewModel除了要响应用户操作，还需要维护视图状态。
在MVP中，Presenter也需要维护视图状态，只不过，Presenter会将视图状态设置到View上，Presenter自己并不持有。
在如今的MVVM框架中，很多框架都支持双向绑定，即View与ViewModel隐式绑定（不需要手动写，全由工具在编译时生成绑定）。
优点：
- View只负责显示与交互，状态交由ViewModel负责；
- 重用View、模型（细粒度才好复用）；
- Mock数据、方便单元测试；
缺点：
- 文件/类也较多，需要良好的目录组织结构；
- 架构的便利性虽然提升了开发效率，同时也隐避了机制原理，需要主动去学习源码，不然不利用个人技术提升；
五、MVPVM
MVPVM.png
基本与MVVM类似，思想是进一步解放View的职责，让每部分功能职责更加单一。
- View只负责展示，不再负责人机交互；
- Presenter负责人机交互；
- ViewModel职责不变；
- Model职责不变；
优缺点同MVVM。
