Qt中所有的模型（Model）都继承自一个公共的抽象基类——QAbstractItemModel类。在这里，抽象的意思是指，这个类不能直接实例化，因为它包含有未实现的方法。程序员只有根据其目的实现缺少的方法，派生一个子类实例化来使用。这就如图8.4所示，每一个模型（Model）也都是一个QObject，因此也能享受到Qt的自动内存管理机制。
QAbstractItemModel并不是模型（Model）继承关系中唯一的抽象类。如果你仔细观察抽象关系结构，你会发现有两个额外的继承自QAbstractItemModel的类，分别叫做QAbstractListModel和QAbstractTableModel，它们的API较之QAbstractItemModel来说，更加细化了，更适合于List view或Table view。
出于兼容性考虑，基于QAbstractListModel和QAbstractTableModel的类理论可以被用在表格（table）、嵌套表格（nested lists）和一维表格（one-dimensional list）。但是，只有你的模型（model）严格地应用在对应的QListView或者QTableView上，才有实际意义。比如说，QAbstractListModel在设计上把可用的列数减少到一，这样对于一个table view，并没有什么意义。
有了QStringListModel，Interview又提供了一种QAbstractListModel的专门实现，它实现了一个可以编辑的model，数据源是一个字符串表（string list）。如果用户在view中修改了字符串，model会对字符串表中相应的条目做出调整。
QStandardItemModel允许数据直接存在model里，这是与理论矛盾的，因为在理论上说model只是数据源与view间的中间服务层。但是之所以还要这么做，是因为在某些数据量要求不大的应用案例中，这么做很实用。对于大型应用程序来说，QStandardItemModel总是太不灵活。
QAbstractProxyModel替换了Qt4.1中的QProxyModel类。QProxyModel类的任务是从model中获取数据、处理他们，然后返回为一个新的Model，举例来说，要过滤数据。但结果是这个类太不灵活，所以最终被替换了。Trolltech建议不要再新的项目中使用这个被替换的类。QAbstractProxyModel很强大，但又来了，他是个抽象类，需要派生子类实现它提供的功能。
既然QProxyModel不再使用了，有新类来替代它，那么新类的使用应当比前者更简单才对，所以Trolltech提供了QSortFilterProxyModel类，主要用来过滤盒排序，而不需要派生子类。
最终Interview提供了一个QDirModel类供开发者使用，如果需要的话，可以在QListView、QTreeView和QTableView中显示目录结构。