从GUI开始
MVC、MVP 以及 MVVM都是GUI设计中的架构模式。
那我们就先从GUI开始,思考下这些模式的本质目的。
什么是GUI?wiki的定义是用于操作计算机的图形界面。
或者使用英文单词(interface)接口能够更加清晰理解它的本质。
GUI就是提供了一种图形化的方式便于用户操作计算机。
在这里插入图片描述
当然这里的操作计算机不仅仅是狭义上的操作计算机硬件,还可以是操作存储,数据库,运行时程序的内存模型等等。
其实从这里我们就可以提取出两个概念。界面(View)和模型(Model)。
GUI程序就是为了解决用户通过View处理Model的需求。
在这里插入图片描述
第一个设计——“MV”模式
既然我们刚刚分析了GUI程序中天然存在View和Model的两个概念,那我们在进行设计时,自然会想到的第一个模型就是上一个小节提出的View-Model模型。
用户通过View上的操作更新Model的数据。Model的数据改变后,更新View的显示状态。
很好,我们有了第一个GUI的设计结构
在这里插入图片描述
我们已经有了一个“MV”模式,但是它真的足够好么?
模式的目的是为了提高复用性,减少开发工作。
我们可以分析下GUI中,哪些是变化的,哪些是不变的?然后把不变的部分抽出。当然我们在处理其他软件设计时,也可以采用类似方式操作。
OK,大部分情况下,Model是不变的,而View是多变的。比如不同主题配色,根据用户操作状态,显示部分数据等等,都会改变View,或者有些软件可以使用一个Model对应多个View
在这里插入图片描述
这样我们每次变更都需要重写整个View。
MVC模式——复用
我们再看一下“MV”模式中,各个部分的职责。
Model是完全被动的,他不知道外面世界的存在,只需要通过观察者模式,再自身数据变更时向外发出通知。
因此可以适应于任意种类,数量的View。
而View,承担了显示Model的数据,以及接收用户输入,并且更新显示状态以及Model数据的功能。
所以"MV"模式中的依赖关系是这样的。
在这里插入图片描述
那么这里面有没有什么是相对来说不变的呢?
有。接收用户输入,并且更新显示状态以及Model数据就是一个相对不变的功能。
试想一个社交类应用。用户可以在注册界面,个人空间等多个地方(View)更改自己的用户名(操作更新Model数据)。但是这类操作是通用逻辑,没有必要每个View都进行实现。
此外例如点击跳转,页面切换等业务,如果写在View中,也会造成View之间的相互耦合,不利于复用。
所以我们可以把这部分业务逻辑抽取到一个单独的模块叫做Controller。
这样我们就更新了三者的职责:
Model:存储数据,在变更时发出通知
View:根据Model的数据进行显示
Controller:接收用户输入,并操作View,以及更新Model
于是我们得到了一个新的模式——MVC模式,它的依赖关系如下。