MVC/MVP开发模式学习浅析

MVC开发模式

关于MVC(Model-View-Controller),即模型-视图-控制器,最早是在1970的时候由TryReenkaug在Smalltalk-80系统上首先提出的,最开始也叫MVC,而是MVCE,多出一个额外的Editor,但最初的理念相差并不大。
MVC其实算是一种框架模式而非设计模式,GOF(GANG OF FOUR)把MVC看作三种设计模式:观察者模式、策略模式与组合模式的合体,其核心在于观察者模式。
其实除了MVC,很多框架模式我们可能都会用到,比如:MVVC、MTV、CBD、ORM和后面将会写到的MVP等。所谓框架,其实就是前人的智慧,对软件设计进行分工,设计模式是小技巧,从而对具体的问题提出具体的方案,从而提高代码的利用率,降低耦合度。

MVC的优缺点

优点
  • 理解简单
    MVC初看上去并不复杂,理解也较为简单,这样而言其实对于开发和维护而言成本会相对较低。
  • 耦合度不高
    因为MVC将表现层和业务层分离实现各司其职,这样的话对开发也较为有利,前端和后端的分离,让每个人都能专注自己的工作。
    缺点
  • 没有清楚的定义,所以MVC了解容易,而深入理解并不容易。从而如果使用它的话需要精心的策划,内部原理也比较复杂。
  • Model和View要求严格分离,这样给调试程序也带来了一定的困难。
  • MVC将一个应用程序分成了3个小部件,这样也就意味着会将同一个工程分解成更多的文件,因此,对于一些小规模的作品,MVC反而会带来更大的工作量。

在Android中MVC的具体实现

其实就Android本身而言,其界面部分就设计到了MVC的模式,因为其用到了模型-试图-控制器三者,并且有着三者的交互。

例如我们可以看一下下面这段常见的Xml布局代码:

1
2
3
4
5
6
7
8
9
10
11
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent">
<ListView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:id="@+id/list">
</ListView>
</RelativeLayout>

而对于Model的Controller而言,自然是我们的Activity来承担了,因为在Android中Activity负责获取数据及界面元素,当然也不能太复杂,因为超过5s系统将会回收这个窗口~

下面是一个简单的数据加载的实例,估计大家都应该见过不少的类似操作,不做多余的说明。

控制器部分

1
2
3
4
5
6
7
8
public class MainActivity extends BaseActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}

数据部分示例展示

1
<?xml version="1.0" encoding="UTF-8"?>
1
2
3
4
5
6
7
8
9
10
11
12
<resources>
<string-array name="Departments">
<item>请选择您的意愿部门</item>
<item>办公室</item>
<item>项目管理部</item>
<item>竞赛活动部</item>
<item>科技人文部</item>
<item>对外合作部</item>
<item>信息部</item>
<item>宣传部</item>
</string-array>
</resources>

每个Item的布局和运行截图也就不贴了,基本listview加载数据的操作大家见得估计也多了~

总结

从例子我们也能看出来,在Android的UI系统中,控制器Activity主要起到的作用是解耦,将视图View和模型Model进行分离,两者在Activity中进行绑定或完成其他逻辑,总体而言,MVC更适合规模较大的项目,比如Android的UI系统框架,但是这个框架是有framework为我们搭建好并提供给我们使用,而非我们自己完成,并不常用到MVC模式去脱离AndroidUI系统构建的自己的框架结构。

MVP应用架构

MVP的作用

MVP模式可以让UI和数据分离,这样应用至少可以分为三层,可以让我们对每个层次进行独立的单元测试。MVP可以让我们从Activity/Fragment等View角色中分离大部分代码,使得每个类型的代码量大幅度减少,职责单一,易于维护。

MVP并不是一个标准化的模式,存在很多种实现方式,所以我们可以根据自己的需要和自己认为对的方式去修正MVP的实现方式,他可以随着Presenter的复杂程度变化,只要保证我们是通过Presenter将View和Model解耦、降低类型复杂度、各个模块可以独立测试独立变化,这就是正确的方向。

MVP的三个角色

Presenter——交互的中间人

Presenter主要作为沟通View和Model的桥梁,它从Model曾检索数据后,返回给View曾,使得View和Model之间没有耦合,也将业务逻辑从View角色上分离出来。

View——界面

View通常是指Activity、Fragment或者某个View控件时,他含有一个Presenter的成员变量,通常View需要实现一个逻辑接口,将View上的操作通过会转交给Presenter进行实现,最后,Presenter调用View逻辑接口将结果返回给View元素。

Model——数据的存取

对于一个结构化的App来说,Model的角色主要是提供数据的存取功能,Presenter需要通过Model层存储获取数据,Model就像一个数据苍老,更直白的说,Model是封装了数据库DAO或者网络获取数据的角色,或者两种数据的获取方式的集合。

与MVC/MVVM的区别

首先:

MVC
  1. 用户可以向View发送指令,再由View直接要求Model改变状态。
  2. 用户也可以直接向Controller发送指令,再由Controller发送给View
  3. Controller起到一个事件路由的作用,同时业务逻辑部署在Controller中。

我们可以看到,MVC的耦合性还是相对较高,View可以直接访问Model,导致三者之间形成回路。
因此MVC和MVP的主要区别是,MVP中的View不能直接访问Model,需要通过Presenter发出请求,View和Model不能直接通信。

MVVM

MVVM和MVP非常相似,唯一的区别是View和Model进行双向绑定,两者只要有一方发生变化就会反映到另一方上,而MVP和MVVM的主要区别是:MVP中的View更新需要通过Presenter,而MVVM不需要,因为View和Model进行了双向绑定,数据的修改会直接反映到View角色上,而View的修改也会导致数据的变更,此时,ViewModel角色需要的只是业务逻辑的处理,以及修改View或者Model的状态,MVVM模式有点像ListView和Adapter的数据集关系。

结构图示

MVP的具体实现

请参考鸿洋博客之:浅谈MVP In Android

笔记资料来源

《Android源码设计模式解析与实战》(人民邮电出版社)

坚持原创技术分享,您的支持将鼓励我继续创作!
0%