8

私はアプリケーションを書いています。さまざまなフォームとそれに対応するデータモジュールがあります。
uses クラスで言及することで、彼らがお互いを使用しているという方法で書きました（相互参照を避けるために、1つは実装で、もう1つはインターフェイスで）このアプローチは間違っていますか？なぜ、またはなぜこのように使用しないのですか?

4

4 に答える 4

9

私はLdsandonに同意する必要があります.IMHOは、プロジェクトに複数のデータモジュールを含める方がはるかに優れています. モデル - ビュー - コントローラーとして見ると、DB がモデル、フォームがビュー、データモジュールがコントローラーになります。

個人的には、プロジェクトには常に少なくとも 2 つのデータモジュールがあります。プロジェクト全体で Actions、ImageLists、DBConnection などを共有するために 1 つのデータモジュールが使用されます。ほとんどの場合、これがメインのデータモジュールです。

そこから、アプリケーションの「エンティティ」ごとに新しいデータ モジュールを作成します。たとえば、私のアプリケーションが注文、カーソル、および製品を処理または表示する必要がある場合、それらのすべてのデータモジュールがあります。

このようにして、機能を明確に分離し、すべてを取り込まなくても簡単に小片を再利用できます。Customers に関連するものが必要な場合は、Customers Datamodule を使用するだけです。

よろしく、

ステファーン

于 2010-11-23T15:22:30.863 に答える
7

特に、関連するデータモジュールの異なるインスタンスを使用して、同じフォームの複数のインスタンスを作成する場合は特に問題ありません。

VCLデザインの小さな問題に注意してください。同じフォームとそのデータモジュールの2つのインスタンスを作成する場合、作成時にちょっとしたトリックを使用しない限り、両方のフォームが同じデータモジュールを指します（VLCがリンクを解決する方法のため）。データモジュールインスタンス：

  if FDataModule = nil then
  begin
    FDataModule := TMyDataModule.Create(Self);
    FDataModule.Name := '';  // That will avoid pointing to the same datamodule
  end;
于 2010-11-23T16:32:39.663 に答える
2

テーブル オブジェクト専用のデータ モジュールは、テーブルが db しかない場合は、最初のモジュールとして適しています。

また、アクション専用のデータ モジュールも別です。

画像リスト専用のデータ モジュールは、もう 1 つの優れた 3 番目のデータ モジュールです。このデータ モジュールにはイメージ リストのみが含まれているため、イメージ リストへのアクセスが必要なフォームは、この共有の場所からそれらすべてを使用できます。

200 個のテーブル オブジェクトがある場合、db テーブル用に複数のデータ モジュールが必要になる可能性があります。請求に関係する 20 のテーブルと、HR に関係する別の 20 のテーブルを持つアプリケーションを想像してみてください。InvoicingDataModule と HRDataModule は、それらの内部のテーブルとそれらに対して動作するコードが互いに何も知る必要がない場合、または 1 つのモジュールが「uses」依存関係を持っている場合でも、別々にするとよいでしょう。しかし、その関係は循環的ではありません。その場合でも、よりきめ細かいデータ モジュールのモジュール性が有益な場合があります。

于 2011-01-28T17:56:21.227 に答える
2

鏡の向こうへ。私は常に DataModules の代わりに Forms を使用しています。私はそれが一般的な根拠ではないことを知っています。

私は常に DataModules の代わりに Forms を使用しています。私はそれらを DataMovules と呼んでいます。

論理的に関連するテーブルのグループごとに、そのような DataMovule を 1 つ使用します。

DataModules と Forms はどちらもコンポーネント コンテナーであり、どちらもデータ関連コンポーネントのコンテナーとして効果的に使用できるため、DataModules の代わりに Forms を使用します。

開発中:

  • 私のアプリケーションは開発が簡単です。フォームは、データ コンポーネントを表示する機会を提供し、それらのコンポーネントの開発を容易にします。
  • 私のアプリケーションは、実際にデータを表示できるようにビューアー コンポーネントをすぐに配置できるため、デバッグが容易です。私は通常、テーブルごとに 1 ページのタブ ラックを作成し、テーブル上のデータを参照するために各ページに 1 つのデータグリッドを作成します。
  • 私のアプリケーションは、たとえばストレス テストで極端な値を試すなど、最終的にデータを操作する可能性があるため、テストが容易です。

開発後:

  • 私は形を見えなくします。実際に DataModule にすることで、データ モジュールとまったく同じコンテナー機能を利用できます。

  • でもボーナス付き。フォームはまだそこにあるので、最終的には問題判別のために表示できるようになるかもしれません。これには About Box を使用します。

いいえ、アプリケーションのサイズやパフォーマンスに目立ったペナルティを感じたことはありません。

私は MVC パラダイムを壊そうとはしません。代わりにそれに従うようにしています。ビューを構成するフォームと、コントローラーを構成する DataMovules を混在させません。私はそれらを私のビューの一部とは考えていません。アプリケーションのユーザー インターフェイスとして使用されることはありません。DataMovules はたまたまフォームです。それらは単なる便利なエンジニアリング アーティファクトです。

于 2010-11-23T17:48:57.677 に答える