MVC(Model View Controller)：
View 层是界面，Model 层是业务逻辑，Controller 层用来调度 View 层和 Model 层，
将用户界面和业务逻辑合理的组织在一起，起粘合剂的效果
1、数据关系：
① View 接受用户交互请求
② View 将请求转交给 Controller
③ Controller 操作 Model 进行数据更新
④ 数据更新后，Model 通知 View 更新变化的数据
⑤ View 更新变化的数据
注：前 2 步可以替换成用户直接与 Controller 交互
2、通信方式：单向通信
3、MVC 优点：
① 耦合性低，视图层和业务层分离 ==》 允许更改视图层代码而不用重新编译模型和控制器代码
② 重用性高 ③ 生命周期成本低 ④ 部署快
⑤ MVC 使开发和维护用户接口的技术含量降低
⑥ 可维护性高，分离视图层和业务逻辑层
4、MVC 缺点：
① 不适合中小型规模的应用程序
② 视图与控制器间联系过于紧密
③ 视图对模型数据的低效率访问
5、结构实现：
① View：使用 Composite 模式
② View 和 Controller：使用 Strategy 模式
③ Model 和 View：Observer 模式同步消息
6、模式简明：
① Composite 模式：组合模式允许你将对象组合成树形结构来表现”部分-整体“的层次结构，
使得客户以一致的方式处理单个对象以及对象的组合
② Strategy 模式：Controller是View的一个策略，Controller对于View是可替换的，
View和Controller的关系是一对多，在该模式下，一个类的行为或其算法可以在运行时更改
③ Observer 模式：由两部分组成，被观察的对象和观察者，观察者也被称为监听者；对应到 MVC 中，
Model 是被观察的对象，View 是观察者，Model 层一旦发生变化，View 层即被通知更新
MVP(Model-View-Presenter)：
Model 提供数据、View 负责显式、Presenter 负责逻辑处理，与 MVC 一个重大区别是不直接使用 Model
1、数据关系：
① View 接收用户交互请求
② View 将请求转交给 Presenter
③ Presenter 操作 Model 进行数据更新
④ Model 通知 Presenter 数据发生了变化
⑤ Presenter 更新 View 数据
2、通信方式：双向通信
3、MVP 优点：
① 模型与视图完全分离 ==》 可以修改视图而不影响模型
② 可以更高效地使用模型 《== 所有交互都发生在 Presenter 内部
③ 可以将一个 Presenter 用于多个视图而不需要改变 Presenter 的逻辑
④ 便于测试 《== 逻辑都放在 Presenter 中，可脱离用户接口来测试逻辑
4、MVP 缺点：
View 和 Presenter 的交互过于频繁
5、结构实现：
① View：使用 Composite 模式
② View 和 Presenter：使用 Mediator 模式
③ Model 和 Presenter：使用 Command 模式同步信息
6、 模式简明：
① Mediator 模式：定义了一种封装对象之间交互的中介
② Command 模式：所有动作或者行为所需信息被封装到一个对象之内，解耦了发送者与接收者之间的联系
Command 是无状态且惰性的，只有在需要的时候才被创建
MVVM(Model-View-ViewModel)：
MVP 模式和 WPF 结合的应用方式发展演变过来的一种新型架构模式
1、数据关系：
① View 接收用户交互请求
② View 将请求转交给 ViewModel
③ ViewModel 操作 Model 数据更新
④ Model 更新完数据，通知 ViewModel 数据发生变化
⑤ ViewModel 更新 View 数据
2、通信方式：双向绑定（View/Model 变化，自动反映在 ViewModel，反之亦然）
3、MVVM 优点：
① 低耦合，View 可独立于 Model 变化和修改，一个 ViewModel 可绑定到不同的 “View” 上，
当 View 变化时 Model 可不变，反之亦然
② 可重用性，可把一些视图逻辑放在一个 ViewModel 里，让多个 View 重用这段视图逻辑
③ 独立开发，不同人员可注重不同的部分
④ 界面素来是比较难于测试的，而现在测试可以针对ViewModel来写
4、MVVM 和 MVP 的区别：
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
唯一的区别是，它采用双向绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。
这样开发者就不用处理接收事件和View更新的工作，框架已经帮你做好了。