14

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

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

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

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

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

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

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

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

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

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

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

4

2 に答える 2

16

これら2つの間に2つの主な違いがあります。

  1. コマンドに対して実行できます。コマンドは、Command.RaiseCanExecuteChanged()を呼び出し、そのCanExecuteデリゲートがfalseを返すようにすることで、実行が有効かどうかを判断できます。複数の「保存」コマンドを合成する「すべて保存」CompositeCommandの場合を考えますが、コマンドの1つが実行できないと言っている場合、「すべて保存」ボタンは自動的に無効になります(いいですね!)。
  2. EventAggregatorはメッセージングパターンであり、CommandsはCommandingパターンです。CompositeCommandsは明示的にUIパターンではありませんが、暗黙的にそうです(通常、ボタンクリックなどの入力アクションに接続されます)。EventAggregatorはこの方法ではありません。アプリケーションのどの部分でも、バックグラウンドプロセス、ViewModelsなどのEventAggregatorイベントを効果的に発生させます。これは、フィルタリング、バックグラウンドスレッドの実行などをサポートする、アプリケーション全体のメッセージングのための仲介手段です。

これが違いを説明するのに役立つことを願っています。それぞれをいつ使用するかを言うのは難しいですが、一般的に私は経験則を使用して、イベントを発生させるのがユーザーインタラクションである場合は、他のコマンドを使用し、EventAggregatorを使用します

お役に立てれば。

于 2009-10-05T17:47:36.047 に答える
7

さらに、もう1つの重要な違いがあります。現在の実装では、EventAggregatorからのイベントは非同期ですが、CompositeCommandは同期です。

「イベントXが発生したことを通知し、イベントXが実行されるようにイベントハンドラーに依存する何かを実行する」などの実装を行う場合は、Application.DoEvents()などを実行するか、CompositeCommandsを使用する必要があります。

于 2010-09-06T06:56:41.657 に答える