模型－视图－控制器（ MVC ）是一个起源于 Smalltalk 的设计模式，它经常在构建用户界面的时候被使用。在设计模式（ Design Patterns ）中， Gamma et al. 写道：

MVC由三种对象组成。模型是应用程序对象，视图是它的屏幕展示，控制器定义了用户界面对用户输入进行响应的方式。在MVC之前，用户界面的设计倾向于将这些对象混在一起。MVC将它们分离以增加灵活性和重用性。

如果视图和控制器对象被合并，那么结果就是模型／视图架构。这仍然将数据存储的方式与数据 展现给用户的方式分离开了，但是提供了一个基于简单的原则的更简单的框架。这种分离使得在多个不同的视图中展示同一个数据成为可能，并且可以在不更改底层 数据结构的情况下实现新的视图类型。为了允许灵活地处理用户输入，我们引入了 代表 的概念。在这个框架中加入代表的好处是，允许自定义展示数据和编辑数据的方式。

模型／视图架构 模型与一个数据源通信，为架构中的其它组件提供一个 接口 。通信的性质取决于数据源的种类和模型的实现方式。 视图从模型取得 模型索引 ；这些是指向数据项目的引用。通过对模型使用模型索引，视图可以从数据源取得数据项目。 在标准的视图中，一个 代表 渲染数据项目。当一个项目被编辑后，代表直接使用模型索引与模型通信。

一般地，模型／视图类可以分成以上描述的三种类型：模型，视图和代表。每种类型的组件是被 抽象 类定义的，抽象类提供共用的接口，在某些情况下也提供一些功能的默认实现。抽象类是用来被子类化以提供其它组件所预期的完整功能的；这也使得可以编写特殊的组件。 模型，视图和代表互相之间使用 信号 和 信号槽 来通信：

• •. 来自模型的信号告知视图关于数据源的数据发生变化的信息。

• •. 来自视图的信号提供关于用户对于显示的项目进行交互的信息。

• •. 来自代表的信号是在编辑时使用的，用来告知模型和视图关于编辑器的状态的信息。

所有的项目模型都是基于 QAbstractItemModel 类的。这个类定义一个被视图和代表用来访问数据的接口。数据自身不需要被储存在模型中；它可以被保存在一个数据结构中，或者是由一个独立的类提供的仓库、一个文件、一个数据库或者其它的应用程序组件中。

围绕着模型的基本概念是在 模型类 一节中描述的。

QabstractItemModel 提供到数据的接口，该接口足够灵活，可以应对用来展示表格型、列表型和树型数据的视图。然而，在实现用来处理列表和表格型数据结构的模型时， QAbstractListModel 和 QAbstractTableModel 是更好的开始点， 因为它们对公共函数提供了适当的默认实现。它们中的每个类都能被子类化，以提供用来支持特殊种类的列表和表格的模型。

将模型子类化的过程在 创建新模型 一节中描述。

Qt 提供一些现成的模型，它们可以用来处理数据项目：

• •. QStringListModel 用来存储一个由 QString 项目组成的简单的列表。

• •. QStandardItemModel 管理更复杂的由项目组成的树型结构，每个项目都可以包含任意的数据。

• •. QFileSystemModel 提供关于本地文件系统中的文件和目录的信息。

• •. QSqlQueryModel ， QSqlTableModel ， 和 QSqlRelationalTableModel 是用来以模型／视图模式来访问数据库的。

如果这些标准的模型不能满足你的要求，你可以子类化 QAbstractItemModel ， QAbstractListModel ，或 QAbstractTableModel 来创建你自己定义的模型。

有一些从标准视图类派生的便利类，以为依赖于 Qt 的基于项目的项目视图和表格类的应用程序提供便利。它们倾向于被子类化，但是也简单地存在以提供一个与等价的 Qt 3 中的类相似的接口。

这些类的例子包括 QListWidget ， QTreeWidget 和 QTableWidget ；这些类提供与 Qt 3 中的 QListBox ， QListView 和 QTable 类相似的行为。

这些类的灵活性比不上视图类，而且不能用于任意类型的模型。我们建议你在处理项目视图中的数据时使用模型／视图方法，除非你强烈地需要一组基于项目的类。

如果你希望利用模型／视图方法提供的优点，同时又使用一个基于项目的接口，那么考虑一下与 QStandardItemModel 一起使用像 QListView ， QTableView 和 QTreeView 这些视图类。

接下来的一些小节描述 Qt 中使用模型／视图设计模式的方式。每个小节提供一个关于使用的示例，紧接着的一个小节展示如何创建你的自定义组件。