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更新的工作,框架已经帮你做好了。