問題タブ [eventaggregator]

Event Aggregator 設計パターンにおける「パブリッシャー」の役割を明確にしたいと思います。

私の現在のソリューションは、XmlDocument で発生する XmlNode イベントなどの .NET データ イベントを処理します。

質問: Event Aggregator 設計パターンでは、パブリッシャーと見なされるものは何ですか?

Prism と MEF/Unity を使用してかなり大規模なアプリケーションを開発するとき、私は常に、イベント、サービス、またはその両方を使用するかどうかを選択する必要があります。そして、何が最も使いやすいかを決めることはできません。私のアーキテクチャに何か問題があるのか​​もしれません (この決定は最初から行う必要がないため) が、何がわかりません。

典型的な例を次に示します。私のアプリケーションには、メイン ウィンドウと、モジュールまたはユーザー アクションによってオンデマンドで作成される多数のスレーブ ウィンドウがあります。アプリケーションは、コンテンツ自体がモジュールのどこかに作成されている間に、スレーブ ウィンドウのクロムの外観と動作を決定し、ウィンドウの配置などを記憶します。ウィンドウの非表示/表示/前面への移動につながるユーザー アクションも多数あります。これらすべてを実現するために、私は現在、CreateWindow/SetWindowState/.. イベントをリッスンする WindowManager サービスを用意しています。

これには次の利点があります。

• これを使用するクラスは、IEventAggregator (他のイベントのためにほとんどの場合既に使用している) と、WindowManager 自体ではなく、WindowManager によって消費されるイベントについてのみ認識します。
• ViewModel のようなクラスは、ウィンドウを直接扱いません。代わりに、タイトルまたは ID と、必要なものだけをカプセル化する小さなイベント クラスによってそれらを参照します。
• テストでモックするためだけに、別の IWindowManager インターフェイスは必要ありません

そして引き出し：

• WindowManager は完全にスタンドアロンで使用できますが、イベントをサブスクライブする必要があります。または、おそらくより良いのは、他のクラスがそれを処理する必要があることです。
• モーダル ダイアログを表示するように拡張するのはややこしいことです。VM がダイアログを表示するイベントを発生させる場合、ダイアログが閉じられた後にのみ Publish 呼び出しが返されることが非常に重要です。
• WindowManager はサービスとして利用でき、CompositionContainer にあります。とにかくそれを使用しないのはなぜですか?

サービスを直接使用すると、特典/引き出しがシフトするだけで、明確な勝者はないようです.

質問: どちらか一方を選択するためのガイダンス ルールとして何を使用しますか? それとも常にどちらか一方または両方を選択しますか? この決定を下さなければならない、アプリケーションの設計に特に問題があるのでしょうか?

それぞれ独自のビューを持つ2つのビューモデルがあります。

最初のビューモデルには、ビューによって表示される3つのプロパティがあります。

2番目のビューモデルには、そのビューによって表示されるプロパティが1つだけあります。

との間には1対多の関係がPolicyTypeありますTypeOfInvestmentFund.

これらのビューモデルとそのビューは両方とも、親フォーム内のユーザーコントロールとして表示されています。

に使用できる選択肢は、他のビューでTypeOfInvestmentFundどちらPolicyTypeが選択されているかによって異なります。

私には、これら2つのビューモデルを組み合わせることができるように感じます。

a）それらは明らかにいくらか結合されています

b）コントロールは非常に小さくて単純なので、それらを結合しても複雑で管理しにくいオブジェクトは作成されません。

ただし、このデータはかなり無関係です。十分に無関係であるため、ユーザーはフォームの個別の部分にデータを表示する必要があります（したがって、個別のビューに配置されます）。

個人的には、これら2つのビューモデルを組み合わせ、2つの別々のビューを接続して異なる部分を表示する方が、2つのオブジェクト間の通信を管理するよりもはるかにオーバーヘッドが少ないと感じています。

ただし、Prism Event Aggregatorを使用して緩く結合されたイベントを作成することはできます。これを行ったことがない場合でも、管理するのはおそらくそれほど多くありません。これら2つのビューモデルを分離しておくと、関心の分離が維持されます。さらに、開発の後半でこの情報を必要とする他のコントロールが表示された場合、それらを吸収し続けることはできません。したがって、この段階でイベントアグリゲーターを開始すると、イベントが既にサブスクライブできるため、やり直しができなくなります。ビューモデルを組み合わせるだけでは、まだまだ手間がかかります。

これらの2つのうちどちらが「より正しい」ですか？判断の呼びかけは理解できますが、決められないので、決心するための意見を探しています。

のCRUDを実行するアプリケーションがありCollectionますModels。DisplayView常に表示されるモデルごとにがあります。関連付けがクリックされたEditViewときにのみ表示されるもあります。DisplayView

DisplayViewとはEditView、さまざまな親ビューの内部に表示されます。現在、「イベントアグリゲーター」パターンを使用して、aがクリックされたEditViewときにレンダリングするようにアプリケーションに指示しています。DisplayViewここで説明するパターン：http：//lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/

私の1つDisplayViewがクリックされると、その親がEditViewsリッスンするイベントが発生します。このイベントを受信するEditViewと、イベントが発生したモデルに基づいて、適切なをレンダリングします。

これは私のアプリケーションのほとんどでうまく機能しますが、アプリケーション内EditViewの関連するものの絶対位置に基づいて位置を変更したい場合は特に面倒DisplayViewです。DisplayViewの位置を直接制御するのではなくEditView、「これらの座標に自分を再配置してください」イベントをトリガーします。このような直接通信は、アプリケーション全体にブロードキャストする必要があるもののようには感じられません。私の場合、それらを分離するのではなくEditView、それぞれのプロパティとして適切なものへの参照を持っているべきかどうか疑問に思い始めています。DisplayView

問題は、私が言ったように、それらが異なる親ビュー内にレンダリングされることです。DisplayViewsgetはでレンダリングされ、HeaderViewgetはでEditViewsレンダリングされますContentView。

他の人はこのような状況をどのように処理しますか？はEditViewいくつかの点でに属しますDisplayViewが、それは私のアプリケーションのDOMの構造とは一致しません。EditViewそれぞれとの間に直接リンクを作成すると仮定するとDisplayView、の表示/非表示をどのように処理しEditViewますか？DisplayViewコンテナへの参照も必要でしょうかContentView。これは、適切なEditViewパラメータを使用して明示的にレンダリングされますか？

Silverlight-MVVMアプリケーションでは、さまざまなビューモデル間で通信するために、ある種のメディエーター/アグリゲーターファイルを使用する必要があります。

しかし、これらのファイルがオブジェクトのリスト（または辞書）を維持していることがわかります...

これは大量のメモリを使用しているのではないでしょうか...？そして、Webアプリケーションの場合（WPFの場合、それは問題ありません）...これは推奨されるものですか？

どんな助けでもいただければ幸いです。前もって感謝します！

モジュールの ViewModel 間の疎結合通信に Prism の EventAggregator を使用しています。ViewModelAにいくつかのプロパティ (FirstName、LastName など) があり、値が変更されたときにViewModelBのプロパティを更新する必要があります。私の現在の解決策は次のとおりです。

ViewModelAは、FirstName の新しい値をペイロードとしてイベントを発行します。

ViewModelBは Event にサブスクライブされ、それに応じて FirstName プロパティを変更します。

これは、単一のプロパティに対して正常に機能します。ViewModelBはViewModelAで変更されたプロパティがわからないため、複数の異なるプロパティでは機能しません。ViewModelB は新しい値が何であるかを認識していますが、どのプロパティを更新するかは認識していません。

プロパティごとに個別のイベントを作成できますが、これは繰り返しのようです。Event を 1 つだけ使用する方がきれいに見えます。理想的には、イベントを発行するときに、ViewModelA が ViewModelB に変更されたプロパティを通知する必要があります。これどうやってするの？

SQL Server に保存されたイベント名でイベントを発生させたい

SQL Server には ApplicationExitRequestEvent があります。メニュー ボタンをクリックすると、MenuItem から文字列が取得されます。

することは可能ですか？PRISM と MVVM の操作 - WPF - .NET 4.0

私はさまざまなオープンソース プロジェクトを通じて、人々が同じ問題にさまざまな方法でアプローチする方法を感じ取っています。今回は Event Aggregators で、具体的には Caliburn.Micro のものです。

Rob が、スレッドが提供されない場合、EA は UI スレッドにマーシャリングすると言ったことに気付きました。行は具体的には次のとおりです。

そしてさらに：

彼が理解できないのは、これがUIスレッドで呼び出されるとどのように言うことができるかということです。そうでないアクションを指定しない限り、すべてのアクションがUIスレッドで呼び出されますか? (ところで、どのアクションが呼び出されるかを指定できます。上記の行は、アクションが指定されていない場合のみです)。

WPF と PRISM を使用して WPF アプリケーションを作成しようとしています。MEF と mvvm も使用しています。イベント アグリゲータを使用して相互に通信できる 2 つのビューモデルを持つことは可能ですか? 例えば。ビューモデル A で公開し、ビューモデル B でサブスクライブしますか? もしそうなら、どのように？複数のビューモデルを使用してプログラムを構築しましたが、これらのビューモデルの一部は互いに通信する必要がありますが、イベントアグリゲーターを使用してビューモデル A で公開すると、ビューモデル B のサブスクライブが同じイベントアグリゲーターに属していると認識されないため、ビューモデル B に接続されているビューを更新します。

Silverlight で Prism のイベント アグリゲーターを使用していますが、Subscribe に苦労しています。コードが Subscribe メソッドに到達すると、ハングアップするだけで、次のコード行に進むことはありません。コードを分割すると、_eventAggregator.GetEvent() はイベントの有効なインスタンスを返すようです。コードは間違いなく「購読」にかかっています。ここで何が間違っているのでしょうか？JobCompletedEvent は、別のライブラリ (このライブラリの依存関係) で宣言されています。