QObject作为域对象的基类。过度设计？

Question

我正在为本地SOHO构建POS /库存/簿记应用程序，我想知道是否应将所有域对象都基于QObject。

我来自vba / MS Access编程，我非常厌倦到处编写SQL，复制数据访问代码和东西，我想曾经写过一个很好的数据抽象 - 我想Qt Signal和Slots可能会提供对我而言。

然后，所有模型将只是QObject的列表/树，CRUD表单将修改对象 - ＆gt;然后，对象发出它所属的任何模型的信号，模型发出任何连接到它的视图的信号，bam一切都很好并被抽象掉了。

Qt属性系统对于滚动一个简单的ORM也很有用，因为我设计了自己的表，因此讨厌为你做的ORM ^^

但后来我读了this question，开始想知道我是否过度工程了？

请注意，我知道我永远不会离开不再在应用程序内部编写SQL，直到LINQ很快就来到C ++ ^^ ......但关键是我正在尝试至少做一件事这次。

Answer 1

QObjects有一些您可能不希望在数据类中使用的奇怪属性：

1. 他们内置了所有权树。每个QObject都维护一个父指针及其子项列表（删除时删除它）。
2. 他们被视为“实体” - 这意味着他们无法复制。没有复制构造函数，也没有赋值运算符。出于这个原因（并且为了避免来自＃1的膨胀），QT数据类型（QString，QHash等）不是QObject。

如果你决定不想要/不需要这些，我建议改为：保持你的班级“vanilla”，但将存储在QAbstractItemModel的QObject后代中。这样可以使您的数据类尽可能小，但允许您在QAbstractItemView的任何后代中以最少的工作量显示它们。然后，您的模型将获得操作底层数据类所需的任何信号和插槽。

事实上，即使您做制作数据类QObjects，让模型“管理”该集合也是一个不错的主意。它只是一些额外的代码，它使显示事物变得清晰。

希望这很有用！