17.3.1  模型、视图和控制器模式

CHelloWorldAppView::Draw()函数假定所需要的数据已经是可用的。它不去询问数据库或用户索取要绘制的字符串，而是使用已经存在控件iHelloWorld成员中的数据。 这是图形的标准范例：绘制函数只是绘制它们的模型数据，它们不改变任何东西。如果想要改变什么，则使用另一个函数，然后调用绘制函数来反映所做的更新。事实上，这一模式是如此通用，以致拥有以下名字：模型-视图-控制器（model-view-controller），通常缩写为MVC。

模型是程序操作的数据：“在Hello World”的例子中，它是字符串文本。

视图是用户用以查看模型的视图：在“Hello World”的例子中，它是ChelloWorldAppView类。

控制器是程序更新模型、并在其后请求视图重绘以显示更新的部分。在“Hello World”中，没有更新，因此没有控制器。当我们研究连三子应用程序时，控制器将相当复杂，因为更新可能通过用户交互产生。 严格的MVC结构如图17.5所示。

模型是独立的实体；如果程序是基于文件的，模型常常与程序的持久性数据相对应。

视图依赖模型，因为它的工作是绘制模型。

控制器协调模型和视图的更新，因此既依赖模型，也依赖视图。 根据程序设计，以上任一“依赖”关系都可能升级为更强的“聚合”关系。特别是，MVC模式规定“依赖”关系，但没有强制“聚合”关系。

1．模糊MVC的差异

在某些程序中，模型、视图和控制器之间的差异通过类之间的界限清楚地反映出来。但在实践中，有许多理由使这种界限变得模糊。

“Hello World”程序是如此简单，因此进行如此精细地区分没有意义—它的ChelloWorldApp View既包含了模型也包含了视图，但是根本没有控制器。另一方面，连三子应用程序的复杂性，足以使用这一结构，并从中获益匪浅。然而，从 MVC意义上看，该模型与 COandXEngine引擎类并不完全相同；它还包含 COandXController的某些方面，因为该轮到哪个玩家的信息包含在这个类中。因此 MVC 模型和控制器之间的界限与 C++(www.cppentry.com)中引擎和控制器类之间的界限并不十分相同。

复杂的程序反复使用 MVC 模式—对于整个应用程序来说，规模较大，对于应用程序中的交互来说，规模较小。可以这么说，甚至按钮栏也有一个模型（由构造它的资源文件定义进行定义）和一个控制器（位于应用程序框架的某个地方）。

当对某些类型的用户交互进行反馈时，MVC范例可能变得特别模糊。这类交互包括导航、光标选择、动画或者拖放（在Symbian操作系统中很少，但确实存在，比如在Symbian操作系统电子表格中重新调整网格列的大小时）。虽然如此，它仍是特别有用的，可以用它来构思许多Symbian操作系统控件和应用程序的设计。

2．MVC中使用的术语

本节的最后谈谈 MVC 中的一个术语。Symbian 操作系统中的“控件（control）”通常不是MVC 意义上的“控制器（controller）”。然而，Symbian 操作系统控件通常确实包含纯粹的 MVC视图功能：它的Draw()函数绘制模型，并且不改变模型。

在 Symbian操作系统文献中，术语“视图（View）”用来表示控件或某些绘图/交互代码，从而突出“视图”是完全和“模型”分开的事实。Symbian操作系统的富文本组件ETEXT和FORM就是很好的例子：ETEXT是没有视图的模型，而FORM提供视图但是没有模型。

我们在这一意义上使用“应用程序视图（app view）”，而模型经常是包含在文档类中。在连三子应用程序中，“OandX view”是控件的名称，因为游戏状态模型数据保存在单独的类中。

在 Symbian 操作系统文献中，术语“模型”通常被用来表示能够保存到文件中的应用程序数据。