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中顯示目錄結構。