角色对比
模式 | 角色 | 作用 | 模式 | 角色 | 作用 | 模式 | 角色 | 作用 |
---|---|---|---|---|---|---|---|---|
MVC | Model | 保存数据 | MVP | Model | 保存数据 | MVVM | Model | 保存数据 |
- | View | 用户界面 | - | View | 用户界面 | - | View | 用户界面 |
- | Controller | 业务逻辑 | - | Presenter | 业务逻辑 | - | ViewModel | 数据绑定 |
从上表可知基本所有的模式,都是为了隔离数据、界面和业务逻辑,这三个部分。
交互对比
经典MVC的交互方式
交互流程:
用户通过操作View触发Controller来对Model进行操作,而Model通过观察者模式更新界面的显示。 可以看出来View和Controller只存在调用关系 ,Controller和Modle也只存在调用关系,到了View和Model也只存在通知变动的关系。严格按照这样设计并实施可以实现业务逻辑,数据和视图的解耦。只要一开始设计的好,可以保证业务逻辑变动时,其他View和Model模块完全都不需要修改。
经典MVP的交互方式
交互流程:
用户通过操作View,触发Presenter去操作Model,而Model当数据更新完之后在通知Presenter去更新视图。 MVP模式下,View是可以完全组件化的,只要实现了接口就可以使用,这样方便测试,也完全隔离了View和Model。唯一的缺点就是Presenter的膨胀,所有业务逻辑,交互逻辑全都在Presenter中会导致Presenter变得特别大。
经典MVVM的交互方式
交互流程:
MVVM模式比MVP就只是把更新View的操作抽离出来,与Model进行绑定,Binder来确保View和Model状态一致。 这样的设计可以把大量MVP中,View和Model的同步操作从Presenter移动到ViewModel的Binder中去,解耦部分ViewModel的操作。
作者只是简单对比了一下经典的常见模式,只是让自己方便记忆。想要深入的了解可以参考一下的文章,说的比较详细。
参考文章
- 阮一峰的网络日志——MVC,MVP 和 MVVM 的图示
- Linux公社——界面之下:还原真实的 MVC、MVP、MVVM 模式