1

私は、他のアプリケーションでも使用されるいくつかのモジュールで構成されるアプリケーションに取り組んでいます。これらの各モジュールにはいくつかの構成オプションが必要ですが、他のモジュールのオプションを認識してはならず、他のモジュールが存在する必要もありません。一部の設定はモジュール間で共有されます。

モジュール A には x と y の設定が必要で、モジュール B には y と z の設定が必要だとします。

設定は、レジストリまたは 1 つ以上の .ini ファイルに保存されます。

これまでのところ、次のアプローチを検討してきました。

  1. すべてのモジュールに含まれ、設定を含むグローバル変数を含むグローバル ユニット (「global.pas」) を用意します。このアプローチはあまり好きではありません。すべてのアプリケーションにそのようなユニットが必要になり、元の目的とは関係のない多くの追加コードを収集することになるからです。したがって、最終的には、各アプリケーションが独自の互換性のないグローバル ユニットを持つことになります。
  2. そのモジュールに必要なすべての設定を含む各モジュールの構成クラスを用意します。これらは、アプリケーションの中心点からモジュールに渡され、永続的な形式への読み取りと書き込みも処理されます (たとえば、JvAppStorage を使用します)。一部のオプションはモジュール間で共有されるため、これにはモジュール間の同期が必要です。そのため、あるモジュールでオプションが変更された場合、この変更は別のモジュールの構成に反映される必要があります (必ずしもリアルタイムではなく、次回のモジュール初期化されます）。
  3. 各モジュールに渡され、すべてのモジュールの設定をプロパティとして含む汎用構成クラスを用意します。各モジュールは、認識している設定のみにアクセスします。ここでの問題は、気付かないうちに名前の衝突が発生する可能性があることです。また、モジュールに不要な構成オプションを渡すという考えも好きではありません。さらに、すべてのアプリケーションにはモジュールの異なるサブセットが含まれますが、可能なすべてのモジュールのオプションを持つ同じ構成クラスが含まれることになります。(これは、上記のグローバル ユニット アプローチと大差ありません。)
  4. 上記のように、各モジュールに渡される汎用構成クラスを用意します。ただし、モジュールはプロパティを持つ代わりに、名前で設定にアクセスします (最も簡単な場合、これは TCustomIniFile になります)。これにより、すべてのアプリケーションですべてのモジュールの設定が使用可能になることは回避されますが、型の互換性の問題が発生する可能性があり、名前の衝突が問題になる可能性があります (各モジュールがそのオプションにその名前のプレフィックスを付けない限り、それらはオプションを共有できなくなります)。

モジュール化されたシステムを書いた人なら誰でもこの問題に直面し、気に入るかどうかにかかわらず、後になって行き詰まった解決策を見つけたことがあると思います。私も何度かそこに行ったことがありますが、今でも黄金の弾丸を探しています。

他の誰かがすでに理想的な解決策を見つけているのではないでしょうか?

（これは、重要な場合に備えて Delphi 2007 です。私はすでに JCL / JVCL を使用しています。）

4

2 に答える 2

3

おそらく、一般的な構成クラスを作成し、各モジュールがシングルトンである 1 つまたは複数の具体的な構成クラスに依存するようにします。モジュールは、そのモジュールのみに重要な設定を持つ構成クラス インスタンスに依存し、オプションで、複数のモジュールに関連する設定を持つ 1 つ以上の他の構成クラス インスタンスに依存します。構成オブジェクトがシングルトンであるため、構成オブジェクトを共有するモジュールは自動的に同じ設定を取得します。

モジュールの使用法に従ってではなく、機能に従って構成クラスを作成します。モジュールが使用する機能は、モジュールが必要とする構成オブジェクトを暗示します。

アプリケーションに追加されるすべてのモジュールは、必要なすべての構成クラスを依存関係として追加します。他の構成クラスは追加されません。シングルトン構成オブジェクトは、アプリケーションの起動時に、そのようなオブジェクトのリスト (必要に応じてレジストリ) に自身を追加します。アプリケーション自体は詳細を知る必要はなく、永続ストレージとの間で設定を読み込んで保存するだけで十分です。必要に応じて、OTOH は同じインフラストラクチャを利用できます。

通常、私はインターフェースに関してすべてを実装し、永続化メカニズムは外部に残します。したがって、後で自由に INI ファイル、レジストリ、またはデータベースに構成を含めることができます (これにより、構成変更の履歴を実装する簡単な方法が得られます)。クラスの階層ではなくインターフェイスに対してプログラミングを始めて以来、私は物事を行う方法にあまり縛られていないことに気付きました。

于 2009-01-27T09:21:53.870 に答える
0

私はかつてそのようなアプリケーションを持っていました（C++Builderで書かれました）。1 つの基本モジュール (BaseClass.BPL) があり、他のすべて (Payment.BPL など) は から継承されました。したがって、基本クラスを使用して共通パラメーターを読み取り、継承されたモジュールを上書きして特定の設定を読み取ることができます。

void PaymentForm::Readsettings()
{
   BaseClass::ReadSettings(); //to read common stuff
   IniFile->ReadString("Payment Module", "setting1,...); //read specific stuff
}

設定を INI ファイルに保存しました。そのレジストリの処理がはるかに簡単になりました。類似した名前の衝突を避けるために、各モジュールは INI で異なるセクションを使用しました。

[Common]
Datapath=...
Server=...

[MainModule]
setting1=..

[Payment module]
setting1=....
setting3=....
于 2009-01-27T09:02:32.757 に答える