WPF ICommand vs RoutedCommand
ボタンCommandプロパティをカスタムコマンドにバインドしてみましょう。
ICommandをいつ実装し、RoutedCommandから派生させるのですか？ RoutedCommandはICommandを実装していますであることがわかります。
どの場合にICommandを実装する必要がありますか？ MVVMモデルはどうですか？どちらがこの目的に適していますか？
お気づきのとおり、 RoutedCommand class はICommandインターフェイスの実装であり、その機能がRoutedEventの機能に類似している場合の主な違いは次のとおりです。
RoutedCommandのExecuteメソッドとCanExecuteメソッドには、通常のICommandの場合のようにコマンドのアプリケーションロジックが含まれていませんが、これらのメソッドは、CommandBindingでオブジェクトを探す要素ツリーをトラバースするイベントを発生させます。 CommandBindingにアタッチされたイベントハンドラーには、コマンドロジックが含まれています。
Executeメソッドは、PreviewExecutedおよびExecutedイベントを発生させます。 CanExecuteメソッドは、PreviewCanExecuteイベントとCanExecuteイベントを発生させます。
RoutedCommandの動作が望ましくない場合は、独自のICommandの実装を確認します。 MVVMパターンに関しては、1つのソリューションとは言えませんが、誰もが独自の方法論を持っているようです。しかし、ここで私が遭遇したこの問題へのいくつかのアプローチがあります：
- WPFのViewModelでRoutedCommandsを使用
- コマンドロジックのリレー
- シンプルコマンド （リレーコマンドとほぼ同じですが、読む価値があります）
Rich McGuireの答えに追加する唯一のことは、RoutedCommands（およびより一般的な子孫 RoutedUICommand がイベントハンドラーと連携して正しく動作する必要があるということです。
私が遭遇したほとんどのMVVM実装は、ViewModelに対するバインディングを活用しようとするため、ViewModel（Viewではなく）がCanExecute/Executeロジックを所有しています。
対照的に、イベントハンドラーはその負担をビューに移動します。その後、処理をViewModelに伝播できますが、これはViewModelとViewの間の結合度がわずかに高いことを意味します（キャスト+メソッド呼び出しなど）。