WPF ICommandとRoutedCommandの比較

Question

カスタムコマンドにバインドされたボタンCommandがあります。

いつICommandを実装する必要がありますか？RoutedCommandから派生するタイミングを教えてください。私はRoutedCommandがICommandを実装していることがわかります。

この場合、ICommandを解読する必要がありますか？ MVVMモデルはどうですか？この目的のためにどちらが適していますか？あなたがRoutedCommand class気づいてきたように

Answer 1

はICommandインタフェースの実装である、その主な違いであれば、その機能は、のと同様であるRoutedEvent：

実行し、RoutedCommandの上のCanExecuteメソッドが含まれていません。コマンドのアプリケーションロジックは典型的なICommandの場合と同じですが、これらのメソッドは要素ツリーを走査してCommandBindingでオブジェクトを探すイベントを発生させます。 CommandBindingに添付されたイベントハンドラには、コマンドロジックが含まれています。

Executeメソッドは、PreviewExecutedイベントとExecutedイベントを発生させます。 CanExecuteメソッドは、PreviewCanExecuteイベントとCanExecuteイベントを発生させます。あなたはICommandの独自の実装を見ていることでしょうRoutedCommandの振る舞いをしたくない場合は

。 MVVMパターンに関しては、私はその1つの解決策を言うことはできません、誰もが独自の方法論を持っているようです。

• Using RoutedCommands with a ViewModel in WPF
• Relaying Command Logic
• Simple Command（ほとんど同じコマンドが、一読の価値を中継する）

Answer 2

のみ：しかし、ここで私が遭遇してきたこの問題にはいくつかのアプローチがありますリッチ・マクガイアの答えに追加するものは、RoutedCommands（およびそれらのより一般的な子孫RoutedUICommandは、正常に動作するようにイベントハンドラを組み込む必要があるということです）

MVVMのほとんどの実装私はViewModelとのバインディングを活用しようとしているため、ViewModel（ビューではなく）がCanExecute/Executeロジックを所有しています。

対照的に、イベントハンドラはその負担をビューに移します。この処理はViewModelに伝播できますが、これはViewModelとView（キャスト+メソッド呼び出しなど）の結合度がやや高いことを意味します。