2

我正在为本地 SOHO 构建一个 POS/Inventory/Bookkeeping 应用程序，我想知道是否应该将我的所有域对象都基于 QObject。

我来自 vba/MS Access 编程，非常讨厌到处写 SQL，复制数据访问代码等等，我想一次写一个很好的数据抽象——我想 Qt Signal 和 Slots 可能会为我提供这些.

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

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

但是后来我读了这个问题，并开始怀疑我是否过度设计了这个？

请注意，我知道我再也不会在应用程序中不编写 SQL 了，直到 LINQ 很快进入 C++ ^^... 但关键是我这次至少要尝试做一件事。

4

1 回答 1

2

QObjects 有一些你可能不希望在数据类中出现的奇怪属性：

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

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

事实上，即使您确实将数据类设为 QObject，让模型“管理”集合也是一个不错的主意。这只是一点点额外的代码，它使显示内容变得非常容易。

希望这有用！

于 2012-07-20T19:38:16.270 回答