MVC，MVP，MVVM基本原理
模式与框架，其诞生就是为了解决日益复杂的事务处理
当同一问题不断出现，人们就会总结细分出相应的问题解决办法
当需求变得庞大的时候，就会出现细分，在细分的过程中就会出现不同的解决办法
在界面、数据、事件、业务这些元素的细分下，出现了最早的模式MVC
MVC 即 Model-View-Controller
Model-View-Controller 模型 视图 控制器
MVC、MVP、MVVM、Code Behind等等都源自于职能分化和规划的思想与目的，MVC只是他们的开始
MVC流程一般是这样的：View层触发事件 Controller处理业务 之后触发数据更新、 不知道谁更新的 Model回到了View View更新数据
MVC在你出现数据变化的时候需要同时维护三个对象和三个交互，这使得事务复杂化了，人们在解决这一问题的时候诞生了新的优化模式MVP
MVP Model-View-Presenter模式
MVP 的模式 切断了 View 和 Model 的联系，使得View只和Presenter联系（Controller）交互，减少了在变化中需要维护的对象的数量
MVP定义了Presenter和View之间的接口，让一些可以根据已有的接口协议去各自分别独立开发，以此去解决界面需求变化频繁的问题
计算机依赖摩尔定律用数量的增长来解决问题，而人是用方式的改变来解决问题的
人们更倾向于低成本，易理解的解决方案
需求变化最频繁的并不一定是最接近用户的界面，但基本可以确定的是，最接近用户的界面是因为需求变化而需要最频繁更改的
MVVM
vm ViewModel大致上就是MVC和MVP中的Presenter和Controller
在MVVM中 View与ViewModel直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步
比起MVP，MVVM不仅简化了业务与界面的依赖关系，还优化了数据频繁更新的解决方案，甚至可以说提供了一种有效的解决模式，
MVVM的好处
- 低耦合。View可以独立于Model变化和修改，一个ViewModel可以绑定到不同的View上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
- 可重用性。可以把一些视图的逻辑放在ViewModel里面，让很多View重用这段视图逻辑。
- 独立开发。开发人员可以专注与业务逻辑和数据的开发(ViewModel)。设计人员可以专注于界面(View)的设计。
- 可测试性。可以针对ViewModel来对界面(View)进行测试
使用 MVVM 模式，程序的 UI 和其背后的展现与业务逻辑将被分离至三个类中：
- 1-视图，封装 UI 与 UI 逻辑
- 2-模型视图，封装展示逻辑与状态
- 3-模型，封装程序的业务逻辑以及数据
单向绑定与双向绑定
- 所谓“单向绑定”就是 ViewModel 变化时，自动更新 View
- 所谓“双向绑定”就是在单向绑定的基础上 View 变化时，自动更新 ViewModel
具体详情后面再详加介绍