QML中包含对象的QABSTRACTLISTMODEL的缺点

Question

qt提供了将C 模型与QML相结合的可能性，并建议文档中的三种方法：

• QStringList
• QObjectList
• QAbstractItemModel

两个前者非常易于使用，例如QObjectList：

// in C++
QList<QObject*> dataList;
dataList.append(new DataObject("Item 1", "red"));
// in QML
ListView {
    model: dataList
    delegate: Text { text: name }
}

，但他们俩都有一个强烈的警告：

注意：没有办法知道一个内容 QLIST发生了变化。如果QLIST发生了变化，则有必要重置 模型[...]

QAbstractItemModel很难与对象一起使用，因为对象属性不是直接暴露的，因此将它们保持在同步需要大量努力。

但是，可以将QList包裹在QAbstractItemModel中并获得超简单的模型。请参阅此处：实施1，实施2

---

QT不在本地实施它的原因是有原因的吗？表现？内存管理问题？这似乎是一个好主意，对于ObjectModel，他们已经实施了类似的东西。

Answer 1

QObject用作模型项目的突出缺点是因为基类非常大，它是一个"上帝对象"(这是一个反pattern(其中包含很多您在大多数情况下实际上并不需要的东西。结果，在您可能拥有的任何模型数据的基础上，它具有大约160个字节的"开销"。如果您有很多项目，并且项目本身相对较小，那可能会有问题。您最终得到了很多开销。

QObjectList作为模型总是一个坏主意，除非您做的事情是完全微不足道的。由于它没有实施适当的接口来通知更改的引用视图，因此唯一的方法是强制更新，这将每次重新制定整个模型，而不仅仅是更改。

只要您正确实现该模型，就不需要哪些项目对象。

第二个实现的原因是多种原因：

• 您无需费心实施具有固定角色的特定"静态"模型，以适用于每个用法方案
• 您的模型项目可能具有根本不同的属性，您不仅限于模型"架构"
• 您会自动收到QML绑定的通知，因为您正在处理QObject和Q_PROPERTY
• 您可以在声明性中定义模型，甚至可以嵌套模型来创建树结构，您不能使用ListModel进行。
• 您可以在纯QML中定义实际模型项，而无需始终重新编译，也就是快速原型制作，并且完成后，您可以简单地将对象移植到C
• 同时，除了所有优点之外，该模型实际上比常规的"刚性"模型要简单得多，因此角色查找更快，因为您本质上具有单个object角色，并且没有查找无论如何，无需实施角色的数据更改信号等... Easy Peasy