2

ローカルSOHO用のPOS/在庫/簿記アプリを作成していますが、すべてのドメインオブジェクトをQObjectに基づいて作成する必要があるかどうか疑問に思いました。

私はvba/MS Accessプログラミングの出身で、どこにでもSQLを記述したり、データアクセスコードを複製したりすることに非常にうんざりしています。データの優れた抽象化を一度書きたいと思っています。QtSignalとSlotsがそれを提供してくれるのではないかと思いました。 。

すべてのモデルは単純にQObjectのリスト/ツリーになり、CRUDフォームはオブジェクトを変更します->オブジェクトは、それが含まれるすべてのモデルに信号を送り、モデルはそれに接続されているすべてのビューに信号を送ります。

Qtプロパティシステムは、単純なORMをロールするのにも役立ちます。これは、私が独自のテーブルを設計しているため、それを実行するORMが嫌いなためです^^

しかし、それから私はこの質問を読んで、私がこれをオーバーエンジニアリングしたのだろうかと思い始めますか？

念のために言っておきますが、LINQがC ++にすぐに登場するまでは、アプリ内でSQLを記述しないことは決してありません^^ ...しかし、重要なのは、今回は少なくとも1つのことを実行しようとしているということです。

4

1 に答える 1

2

QObjectには、データクラスには必要ない可能性のある奇妙なプロパティがいくつかあります。

  1. 所有権ツリー​​が組み込まれています。各QObjectは、親ポインターとその子のリスト（削除されると削除されます）を保持します。
  2. それらは「エンティティ」と見なされます。つまり、コピーできません。コピーコンストラクタも代入演算子もありません。このため（そして＃1からの肥大化を避けるため）、QTデータ型（QString、QHashなど）はQObjectではありません。

これらが不要/不要であると判断した場合は、代わりに次のことをお勧めします。クラスを「バニラ」のままにして、QAbstractItemModelの子孫であるQObjectに保存します。これにより、データクラスは可能な限り小さくなりますが、最小限の作業でQAbstractItemViewの子孫に表示できます。次に、モデルは、基になるデータクラスを操作するために必要な信号とスロットを取得します。

実際、データクラスをQObjectsにしたとしても、モデルにコレクションを「管理」させることはかなり良い考えです。ほんの少しの余分なコードで、物事をすっきりと簡単に表示できます。

お役に立てば幸いです。

于 2012-07-20T19:38:16.270 に答える