[TOC]
MVC
mvc即model(数据保存)-view(用户界面)-controller(业务逻辑),其目的是为了将数据模型和视图分离开来,并以控制器作为连接两者的桥梁以实现解耦。
mvc三部分的通信如下图,其中所有的通信都是单向的:
MVC是一种框架模式而非设计模式,《设计模式》一书中把MVC看做是三种设计模式:观察者模式、策略模式和组合模式的合体,而且其核心在观察者模式,也就是一个基于发布/订阅者模型的框架,很多时候在实际开发过程中我们常常还会在mvc框架中使用其他的设计模式。
框架模式和设计模式的区别是什么?
在《Android源码设计模式解析与实战》一书中这样描述两者的区别:框架是大智慧,用来对软件设计进行分工;设计模式是小技巧,对具体问题提出解决方案,以提高代码复用率,降低耦合度。
mvc的优点与缺点
mvc的优点很多,首先理解起来比较容易,技术含量并不高,易于开发和维护,其次是耦合性不高,表现层与业务层分离实现各司其职,提高代码重用性。
缺点也很明显,由于要严格区分视图、数据存储和控制器,因此清晰的结构以代码的复杂性为代价,对小项目还有可能降低开发效率,控制层和表现层有时会过于紧密,导致没有真正的分离和重用。
Android中mvc的实现
由于Android中有专用于布局的xml,因此很简单的就可以划分出Android的model、view和controller,视图层一般就采用xml文件进行界面的描述,而数据层model部分大多对应本地的数据文件或网络获取的数据体,很多时候我们对这些数据的处理也会放在这一层,最后的controller则是由activity承担。
总结一下即:
model——本地数据文件或网络获取的数据体;
view——xml文件;
controler——activity;
可见,在Android的mvc框架中,activity占据主导地位,多数逻辑代码会写在activity中,也起到了将view和model层解耦的作用,两者在activity中进行绑定或完成其它逻辑。
实际上,普通的Android项目在进行开发时,framework已经搭建并提供好了足够完善的Android的UI系统框架,所以平时我们并不常用到mvc模式去脱离Android的UI系统构建自己的框架结构。
MVP
mvp是从mvc演化而来的,表示model-view-presenter。MVP能够有效的降低view的复杂性,避免业务逻辑被塞进view中,使得view变成一个混乱的大泥坑。
我们可以看到,通过MVP,view和model层实现了完全的分离,presenter层作为中间人实现view和model的解耦。
MVP模式可以分离显示层和逻辑层,它们之间通过接口进行通信,降低耦合。理想化的MVP可以实现同一份逻辑代码搭配不同的显示界面,因为它们之间并不依赖于具体,而是依赖于抽象。这使得presenter可以运用于任何实现了view逻辑接口的UI,使之具有更广泛的实用性,保证了灵活度。
不难看出,MVP中的三个部分与mvc还是产生了些许不同,一般情况下,MVP中的view层不再指xml文件,而是将activity、fragment、view等作为视图层,model层还是本地数据文件或者网络请求下来的数据体,presenter层与mvc的controller层作用类似,主要承担业务逻辑,另外也承担了view和model的联系。
MVP与MVC、MVVM的区别
mvc的特点
(1)用户可以向view发送指令,再由view直接要求model改变状态
(2)用户也可以直接向controller发送指令,再由controller发送给view
(3)controller起到事件路由的作用,同时业务逻辑都部署在controller中
总的来说,mvc的耦合性还是相对较高,view可以直接访问model,导致三者之间形成回路。因此MVP与mvc之间的主要区别是MVP中的view不能直接访问model,需要通过presenter发出请求,view与model不能直接通信。
mvvm(model-view-ViewModle)的特点
mvvm与MVP非常相似,唯一的区别是view和model进行双向绑定,两者之间有一方发生变化都会反映到另一方上。
mvvm与MVP只要的区别是MVP中的view更新需要通过presenter,而mvvm不需要,因为view和model进行了双向绑定,数据的修改会直接反应到view角色上,而view的修改也会导致数据的变更。此时,ViewModel角色需要做的只是业务逻辑的处理,以及修改view或者model的状态。
mvvm有点像listView、adapter和数据集的关系