从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模式，它的依赖关系如下。