1.1.1 MVC
MVC流程:
MVC的一般流程是这样的：View（界面）触发事件--》Controller（业务）处理了业务，然后触发了数据更新--》不知道谁更新了Model的数据--》Model（带着数据）回到了View--》View更新数据
1.1.2
痛点:
MVC的三角关系导致了 在MVC，当你有变化的时候你需要同时维护三个对象和三个交互，这显然让事情复杂化了。
随着需求变得庞大的时候，需求变化也变得频繁，这是一个出现了无数次以后也将会出现无数的无数次的一个问题，所以它需要一个解决方案，哪怕它不一定能被解决。
1.2.1 MVP（Model View Presenter）
思想:
切断的View和Model的联系，让View只和Presenter（原Controller）交互，减少在需求变化中需要维护的对象的数量。
致力于:
用更低的成本解决问题
用更容易理解的方式解决问题
1.2.3
又是：
MVP定义了Presenter和View之间的接口，让一些可以根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题。
在这里要提到的是，事实上，需求变化最频繁的并不一定是最接近用户的界面，但基本可以确定的是，最接近用户的界面是因为需求变化而需要最频繁更改的
1.3.1 Model View Viewmodel
思想
放弃了 MVP中Presenter和View之间的接口
ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步。
数据绑定你可以认为是Observer模式或者是Publish/Subscribe模式，原理都是为了用一种统一的集中的方式实现频繁需要被实现的数据更新问题。
1.3.2
优势
比起MVP，MVVM不仅简化了业务与界面的依赖关系，还优化了数据频繁更新的解决方案，甚至可以说提供了一种有效的解决模式。
1.4.1 基于WEB的前端设计模式
过去十年却是互联网的时代。实际上大部分让大家争议的并不是在桌面领域最合适的是那个，而是在Web领域的模式问题，也就是在B/S场景下的问题。当软件离开单机，去到网络的时候，因为场景变了，所以原有的解决方案也变了，不过需求依然是不变的。我们依然要解决的问题是用户交互与数据更新的问题，还有维护等等的问题。
1.4.2
痛点
MVVM，MVP用来做服务端是极其不适用的，至少现在是不适用的。
这个时候，我们会更倾向于用MVC模式，因为在Web层面，我们更倾向于一次性更新数据。
1.4.2.1开发成本过高
很多时候你不会愿意为了一个数据更新写一个AJAX，更别说这个AJAX要带来Loading、事件顺序处理、网络问题、异常处理等等，这就是开发成本过高。
1.4.2.2
另一个网络成本过高就更容易解释了，虽然宽带是基本包月的，但也不带这么用的，何况还有移动用户。更主要的原因是，在本地软件，更新数据是一个引用问题，而在网络应用上，这是一个传输问题。传输成本远高于引用成本，引用之上顶多是在本地内存中再进行一次内存拷贝。
1.5 结语
M-V- X 本质都是一样的 重点还是在于M-V 的桥梁 要靠 X来牵线。
X的模式之间不同 主要是 M与V 的数据传递的流程不同。
数据传递的流程不同来源于运行环境技术栈能够做到的事情不同。
所以无论是复杂化 简单化 还是修改流程，基本都是因为技术栈变化了 对应做的调整。
在相同技术栈下 能够实现的各种 X都可以是大同小异的。
在不同技术栈下 相同的X可能实现都大相径庭，仅有非常抽象的流程类似。
