0

私たちのアプリケーションにはいくつかのウィンドウがあります。現在、それらは別々のプロセスで実行されていますが、それによりそれらの間の通信が厄介になります (そして、JMS 接続などのリソースが増加します)。アイデアは、通信とリソース/サービスの共有を容易にするために、単一プロセスに向けて構造をリファクタリングすることでした。

私はこのようにプリズムモジュールを使用することについて考えました:

プリズムモジュール

アイデアは、各ウィンドウの「メイン プログラム」をプリズム モジュールとしてロードし、各モジュールが適切と思われる独自の DI コンテナーを初期化できるようにすることでした (各ウィンドウは異なるチームによって作成されます)。モジュールは、他の UI に貢献することはありませんが、メイン MEF コンテナーを介してサービスを共有する場合があります。Main は、モジュールで利用できるいくつかの一般的なサービスをロードすることもできます。

各モジュールを独自の DI コンテナーに分離することで、モジュール間の依存地獄を回避し、別のモジュールからのサービスのより規律ある使用を奨励しようとしています。

  1. これは可能ですか、それとも DI コンテナーが互いに衝突しますか (同じプロセス内にありますか)?
  2. Prism には、この種のソリューションと戦うものはありますか?
  3. プリズム IModule の代わりに独自のミニモジュールシステムを作成する必要がありますか?

私たちが調査してきた別の可能性は、各モジュールを独自の AppDomain に配置することです。ただし、それには独自の欠点があります (共有サービスは wcf を介して行う必要があるなど)。ただし、個別の AppDomain を使用すると、DI コンテナーの衝突の可能性が回避され、AppDomain に障害が発生した場合にメインがウォッチドッグとして機能することができます。AppDomain ベースのソリューションの経験がある人はいますか? ここに記載されていない問題はありますか?

4

1 に答える 1

0

まず、別々のプロセスでビューを実行することは悪い考えです。次に、プリズムのすべてのアイデアは、すべてのビューを管理する 1 つのプロセスと 1 つの (!) コンテナーで実行することです。ビュー間の通信は、サービスとイベントの集計によって行われます。それらの間に依存関係は必要ありません。例を挙げましょう。あなたのアプリはショップを表しています。野菜を処理する 1 つのモジュール (ビュー、ビュー モデル、モデル) があります。乳製品を処理する 1 つのモジュール (ビュー、ビュー モデル、モデル) があります。各モジュールはデータを取得するために SOAP サービスを使用する必要があります。これは、両方のモジュールに挿入される共有サービスになります。最初のモジュールは、すべての野菜が販売されていることを気にかけているすべての人に伝える必要があります。イベント (集約) を送信し、知る必要があるモジュールはこの種のイベントをリッスンします。等々、モジュール間のすべての通信は、ほとんどが共有サービスとイベント集約によって行われます。私があなたの質問に答えたことを願っています

于 2015-01-07T14:49:07.303 に答える