我正在为本地 SOHO 构建 POS/库存/簿记应用程序，我想知道是否应该将所有域对象基于 QObject。
我来自 vba/MS Access 编程，非常厌倦到处编写 SQL、重复数据访问代码等等，我想一次编写一个好的数据抽象 - 我认为 Qt Signal 和 Slots 可能会提供对我来说。
所有模型都将只是 QObject 的列表/树，CRUD 形式将修改对象 -> 对象，然后向它所属的任何模型发出信号，模型向连接到它的任何 View 发出信号，一切都很好并被抽象掉。
Qt 属性系统对于推出简单的 ORM 也很有用，因为我设计自己的表，因此讨厌为你做这件事的 ORM ^^
但后来我读到 this question ，并开始怀疑我是否对此进行了过度设计？
请注意，我知道我永远不会再在应用程序中编写 SQL，除非 LINQ 很快就会转向 C++ ^^...但重点是我正在尝试至少做正确的一件事这次。
最佳答案
QObjects 有一些奇怪的属性，您可能不希望在数据类中使用这些属性:
- 它们内置了一个所有权树。每个 QObject 都维护一个父指针及其子列表(当它被删除时，它也会删除)。
- 它们被视为“实体” - 这意味着它们无法被复制。没有复制构造函数，也没有赋值运算符。由于这个原因(并为了避免 #1 造成的膨胀)，QT 数据类型(QString、QHash 等)不是 QObject。
如果您决定不想要/不需要这些，我建议您这样做:让您的类保持“普通”，但存储它们在 QAbstractItemModel 的 QObject 后代中。 。这使您的数据类尽可能小，但允许您以 QAbstractItemView 的任何后代显示它们。只需最少的工作。然后，您的模型将获得操作底层数据类所需的任何信号和槽。
事实上，即使您确实将数据类设为 QObject，让模型“管理”集合也是一个非常好的主意。只需要一点点额外的代码，就可以让显示内容变得非常简单。
希望有用!
关于c++ - QObject 作为域对象的基类。过度设计？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11585483/