問題タブ [eventaggregator]

私のCompositeWPFアプリケーションには、ユーザーがコントロールをダブルクリックしたときに公開されるイベントがあります。モジュールはイベントをサブスクライブし、必要に応じてアクションを実行します。

このイベントはランダムに機能しなくなったようです。アプリケーションを実行すると、問題なくイベントをトリガーできる場合もあれば、モジュールがイベントの受信を停止する前に数回しかトリガーできない場合もあります。

デバッガーを見ると、CALにEventAggregatorはまだイベントがありますが、イベントにはサブスクリプションがありません。EventAggregatorサブスクリプションを失うにはどうすればよいですか？

MicrosoftのPrismEventAggregatorfor Javaに相当するものはありますか？

顧客モジュールでイベントを発行しようとしても機能しません (サブスクライバーはオブジェクトを受信せず、何も表示しません):

ただし、この回避策を実行して、イベントを発行するビューモデルのコマンドを呼び出す領域にビューをロードし、ビューを非アクティブにすると、機能します。

意見：

ビューモデル:

この奇妙な回避策を実行する代わりに、モジュールのコンストラクターでイベントを発行するにはどうすればよいですか?

リスナーがIoCコンテナーによって作成されるときに、リスナーのシングルトンイベントアグリゲーターへの自動登録を実装しようとしています。基本的にはJeremy D. Millerが行っていますが、StructureMapの代わりにCastleを使用しています。

したがって、Windsorのオブジェクト作成メカニズムを「インターセプト」できるようにし、オブジェクトがマーカーインターフェイス（たとえば）をサポートしている場合は、メソッドを（コンテナにも登録されているIListener）に呼び出して、新しく作成されたオブジェクトをサブスクライバーにします。イベントに。また、オブジェクトインスタンスがコンテナによって解放される前に、サブスクライブを解除できるようにしたいと思います。SubscribeEventAggregator

このようなことを達成するためにウィンザー城のどのメカニズムを使用すべきかについて少し混乱していますか？私はインターフェースを見始めましたが、オブジェクトへのすべてのIInterceptor呼び出しをインターセプトしているようです。これは私が本当に必要としているものではありません（そしてパフォーマンス上の理由から避けたいです）。

私はPrismのガイダンスを読み進め、彼らのコミュニケーション手段のほとんどを把握できたと思います。

コマンドは非常に単純なので、DelegateCommandは、ビューをそのモデルに接続するためだけに使用されることは明らかです。

クロスモジュール通信に関しては、特に複合コマンドでEventAggregationを使用する場合は、やや明確ではありません。

実用的な効果は同じです例えば

• イベントを公開する->すべてのサブスクライバーが通知を受け取り、それに応じてコードを実行する
• 複合コマンドを実行します->登録されているすべてのコマンドが実行され、それに付随するコードが実行されます

どちらも「ファイアアンドフォーゲット」の方針に沿って機能します。つまり、イベントの発生/コマンドの実行後、サブスクライバーからの応答を気にしません。

両方の実装（内部）は非常に異なることは理解していますが、実際の使用法の違いを理解するのに苦労しています。

それで、それが実際に何を意味するのかを考える必要があります-イベント？それは何かが起こったとき（イベントが起こったとき）ですか？「Webリクエストが完了しました」のように、ユーザーが直接リクエストしなかったものはありますか？

そしてコマンド？これは、ユーザーが何かをクリックしてアプリケーションにコマンドを発行し、サービスを直接要求したことを意味しますか？

それですか？または、これらの通信手段の1つを他の通信手段よりも使用するタイミングを決定する他の方法はありますか。ガイダンスは、私が読んだ最高のドキュメントの1つですが、具体的な説明はありません。

ですから、Prismに関係している/使用している人々が、これに光を当てるのに役立つことを願っています。

メニュー項目をクリックするとEventAggregatorを使用してイベントを公開するMenuコントロールを使用して、アプリケーションを介したナビゲーションを実装しました。以下のようなもの、

私のアプリケーションのほとんどのモジュールは、このイベントのサブスクライバーです。フィルタを使用して、モジュールに関連するイベントのみをサブスクライブします

ビューのリクエストは次のように処理されます。

この実装をどのように評価しますか？あなたがそれが悪いと思うなら、私がそれを改善するのを手伝うか、より良い代替案を提案してください。

バックグラウンドタスクの実行中に、メインフォームのプログレスバーを更新しようとしています。

最新のPatterns＆PracticesリリースルートのEventAggregatorを使用して、アプリケーション全体のイベントをルーティングしています。

私は、BackgroundWorkerイベントをリッスンしているクラスからイベントを発生させており、そのようにイベントを発生させています。

1. bwのプロセスは、進行状況を報告するためにBWメソッドを起動します。
2. BWは、レポートイベントを発生させます。
3. それらは、起動前にBWに設定されたSomeCommandクラスメソッドによって取得されます。
4. EventAggregatorからイベントを公開します

public void ProgressChanged（オブジェクト送信者、ProgressChangedEventArgs ea）{KnownProgressStatusChangedEvent evt = KernelKeeper.Kernel.Get（）。GetEvent（）; evt.Publish（ea）; }

私のMainPresenterは、これらのイベントを次のようにサブスクライブしています。

ThreadOption.UIThreadを設定しないと、スタックトレースのないProgram.csでTargetInvokationExceptionが発生します。このようにして、例外は発生せず、EventAggregatorにステップインできます。

それがKnownProgressChangedメソッドを呼び出そうとしているとき、それはそれを呼び出そうとし、をチェックしApplication.Current != nullます。nullであり、何も発生しません。

私は何を間違っているのですか？お知らせ下さい。

Prism を使用したイベント集約の実装に取り​​組んでいます。いくつかのモジュールがあり、それぞれが要求されたときに通知するイベントにサブスクライブする必要があります。シェルでサブスクライブとパブリッシャーの両方を使用して、単純な例を作成することから始めました。問題ありません。今; サブスクライバーをモジュールに移動すると、トリガーされません。さらに奇妙なのは、実際に数回機能したことです。そのすべてがブレークポイントで保留されています。そのため、競合状態のように思えますが、その理由はわかりません。

仮定: IEventAggregator をどこにでもセットアップする必要はありません。たとえば、IoC コンテナーに登録しますか? これは Prism に組み込まれているため、イベント アグリゲーターのインスタンスは 1 つしかありません。

したがって、問題は基本的に、サブスクライバーをいつ、どこで、どのように設定する必要があるかです。ものなどに特定の順序はありますか？私の簡単な例では、1 つのモジュール MyModule があります。Bootstrapper は MyModule をカタログに追加し、初期化します。

MyModule はアグリゲーターを格納し、これを使用して MyModuleRequestedEvent をサブスクライブします。また、メニュー レジストリを使用してアプリケーション メニューに登録します。アイデアは、最終的にメニューをクリックするとイベントがトリガーされ、要求されたことを MyModule に通知するというものです。次に、さらに何をすべきかを理解するのが MyModule の責任であってほしいと思います。

これで、シェルにこのイベントを発行するボタンができました。シェルは、解決時に同じ (?) イベント アグリゲーターを取得します。

ノート：

• イベントが公開されていることを確認しました。シェルにもサブスクライバーを追加すると、このサブスクライバーはイベントを受信します。
• また; MyModule のサブスクライバーはトリガーされません。しかし、奇妙なことに、それは数回ありました。
• イベントへの入力は使用しません。入力型が必要なようだったので、ダミーの bool を使用しました。これを取り除くことはできますか..？

私はいくつかの宿題をしましたが、各方法をいつ使用するかについてのベストプラクティスに関する記事を見つけることができませんでした..

明確にするために： イベントアグリゲーターパターンを使用する場合：各画面にはビューモデルの独自の参照があり、ビューモデルはイベントアグリゲーターを使用して変更を公開し、後でオブザーバーが状態を同期するために使用します。

ViewModel のキャッシング: すべての画面にはビューモデルの保存参照があり、ビューモデルのプロパティにバインドされているコントロールは同期されます。これは、アプリ内のすべての画面にビューモデルの同じ参照がある (キャッシュから取得した) ためです。画面はデータバインディングのおかげで同期されます。

各アプローチをいつ使用するか それらのそれぞれを使用することの長所と短所は何ですか?