今天和大家简单介绍下GUI设计中MVC、MVP 以及 MVVM 架构模式的演变。

由于MVC等相关模式的定义，实现都各有不同，加之作者认识水平有限，如有纰漏或不足，万望指正。

从GUI开始

MVC、MVP 以及 MVVM都是GUI设计中的架构模式。

那我们就先从GUI开始，思考下这些模式的本质目的。

什么是GUI？wiki的定义是用于操作计算机的图形界面。

或者使用英文单词（interface）接口能够更加清晰理解它的本质。

GUI就是提供了一种图形化的方式便于用户操作计算机。

image-20200308142131368

当然这里的操作计算机不仅仅是狭义上的操作计算机硬件，还可以是操作存储，数据库，运行时程序的内存模型等等。

其实从这里我们就可以提取出两个概念。界面（View）和模型（Model）。

GUI程序就是为了解决用户通过View处理Model的需求。

image-20200308141659491

第一个设计——“MV”模式

既然我们刚刚分析了GUI程序中天然存在View和Model的两个概念，那我们在进行设计时，自然会想到的第一个模型就是上一个小节提出的View-Model模型。

用户通过View上的操作更新Model的数据。Model的数据改变后，更新View的显示状态。

很好，我们有了第一个GUI的设计结构

image-20200308141659491

我们已经有了一个“MV”模式，但是它真的足够好么？

模式的目的是为了提高复用性，减少开发工作。

我们可以分析下GUI中，哪些是变化的，哪些是不变的？然后把不变的部分抽出。当然我们在处理其他软件设计时，也可以采用类似方式操作。

OK，大部分情况下，Model是不变的，而View是多变的。比如不同主题配色，根据用户操作状态，显示部分数据等等，都会改变View，或者有些软件可以使用一个Model对应多个View

image-20200308144327452

这样我们每次变更都需要重写整个View。

MVC模式——复用

我们再看一下“MV”模式中，各个部分的职责。

Model是完全被动的，他不知道外面世界的存在，只需要通过观察者模式，再自身数据变更时向外发出通知。

因此可以适应于任意种类，数量的View。

而View，承担了显示Model的数据，以及接收用户输入，并且更新显示状态以及Model数据的功能。

所以”MV”模式中的依赖关系是这样的。

image-20200308151905840

那么这里面有没有什么是相对来说不变的呢？

有。接收用户输入，并且更新显示状态以及Model数据就是一个相对不变的功能。

试想一个社交类应用。用户可以在注册界面，个人空间等多个地方（View）更改自己的用户名（操作更新Model数据）。但是这类操作是通用逻辑，没有必要每个View都进行实现。

此外例如点击跳转，页面切换等业务，如果写在View中，也会造成View之间的相互耦合，不利于复用。

所以我们可以把这部分业务逻辑抽取到一个单独的模块叫做Controller。

这样我们就更新了三者的职责：

  • Model：存储数据，在变更时发出通知
  • View：根据Model的数据进行显示
  • Controller：接收用户输入，并操作View，以及更新Model

于是我们得到了一个新的模式——MVC模式，它的依赖关系如下。

相比于“MV”模式，一部分通用业务逻辑移动到了Controller，View变得更加轻量，易于扩展更新。

image-20200308152313340

当然，MVC在各个端的定义和实现也没有统一。比如如果没有View切换，Controller也不一定要依赖View。

例如Martin Fowler在这篇GUI Architectures文章中介绍的MVC就没有Controller和View的关键依赖。

image-20200308154049617

各个框架中MVC的实现方式，可以参考浅谈 MVC、MVP 和 MVVM 架构模式，其中有详细介绍，不再赘述。

MVP——可测试

可测试性是软件设计的一个重要的非业务需求。

我们看下MVC的可测试性。

我们都知道UI测试是最困难的测试之一。

由于View自身处理了Model数据渲染的逻辑，而这部分处在View中的逻辑就变得不容易测试了。

这种情况下，最简单的解决方案就是将这部分逻辑移动至容易测试的部分——我们的Controller。

这里因为Controller承担了一部分显示的逻辑，所以为了区分，就将其改名为Presenter。

这样我们就更新了三者的职责：

  • Model：存储数据，在变更时发出通知
  • View：根据Presenter的指导显示
  • Presenter：接收用户输入，决定View显示，以及更新Model

这里根据显示逻辑迁移的多少可以分为Supervising Controller和 Passive View模式

Supervising Controller承担了大部分的复杂逻辑，如下图所示。

image-20200308161958492

而Passive View则是将全部逻辑都交给了Presenter处理。

也正是View没有了渲染逻辑，所以他不需要从Model中拿数据，Model的数据更新只需要通知Presenter。

由Presenter处理后操作View渲染。

这样所有逻辑都可测，而且View同Model完成了解构。

image-20200308162442260

MVP解决了可测试性问题，但是也造成了Presenter的进一步庞大，而且和业务逻辑，甚至是显示逻辑也更加耦合。

MVVM——不同层次的模型抽象

MVVM是MVC的另一个变种，也是目前广泛使用的一种GUI模型。我们常见的WPF框架就是建立在MVVM模式的基础之上。

试想下有这样一个问题，我们要显示用户的博客空间。

我们期望在界面上让用户的昵称显示宋体、加粗、红色。

那么这个宋体、加粗、红色的信息应该放在那里呢？

Model层显然不行，这里的数据属于UI，不属于领域模型，加入Model层只会使Model更加庞大，且冗余。

View层？UI数据随View层的确是个好主意，但是如果这个数据会变化呢？比如当用户点击头像时，用户昵称要加粗；点击简介时，用户昵称不加粗。（大家就当这个设计师没有审美好了，一时间想不出更好的场景。。）

更好的方式仍然是显示和数据分类。

所以我们引入一个新的概念，ViewModel，来赋予Controller存储UI相关数据的能力。

这样我们就更新了三者的职责：

  • Model：存储数据，在变更时发出通知
  • View：根据ViewModel的数据进行显示
  • ViewModel：接收用户输入，更改Model数据，并更加Model的更新，更新自身数据并通知View

所以这三种的依赖变化如下。可以看到我们利用MVVM完成了根据可变性分离的单向依赖模型。

image-20200308165301003

对于WPF框架，还可以使用DataBinding和Command进行进一步解耦。

image-20200308165905308

后记

我们分析总结了GUI模式一步步的演变过程，以及各个模式解决的重点问题。

当然这里并不是说某个模式能够完全胜过另一个模式，而是根据具体场景选择合适的架构。

例如web应用这边使用MVVM就不是很合适，而更适合MVC。（Model和Controller在服务端，而View在用户端）

能够理解和明白各个架构模式的优劣才能够在使用时得心应手。

参考文档：

本文会经常更新，请阅读原文： https://dotnet-campus.github.io//post/MVC-MVP-MVVM%E6%A8%A1%E5%BC%8F%E6%BC%94%E5%8F%98%E7%AE%80%E6%9E%90.html ，以避免陈旧错误知识的误导，同时有更好的阅读体验。

知识共享许可协议 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。欢迎转载、使用、重新发布，但务必保留文章署名 dotnet 职业技术学院 （包含链接： https://dotnet-campus.github.io/ ），不得用于商业目的，基于本文修改后的作品务必以相同的许可发布。如有任何疑问，请 与我联系 。

相关文章