私は WPF アプリに取り組んでおり、コマンド パターンをかなりよく理解していますが、MVVM のコマンド パターンにはいくつかの異なる実装があることがわかりました。Josh Smith の WPF サンプル アプリ、DelegateCommandfrom Prism、および実装には Josh Smith の実装がありCommandBindingsます。
私の質問は、MVVM でコマンドを使用するための一般的に受け入れられているベスト プラクティスは何ですか? 私のアプリケーションは Prism を使用しているためDelegateCommand、利用できます。
私のチームの開発者は、どのアプローチが「最適」かについて議論しています。コマンドごとに多数の .cs ファイルが生成されるのを好まない人もいれば、.cs を介してすべてを接続することを好む人もいますCommandBindings。私は途方に暮れています。誰でも光を当てることができますか？
うーん、解決策はないと思います。
CommandBindings は簡単にはテストできず、ViewModel 内の WPF クラスへの依存関係が発生しますが、これはあまり良くありません。だから私はそれらを使用しません。
DelegateCommand と CommandSinkCommand (Josh Smith のソリューション) はどちらも、IMO の良い方法です。それらは実際には違いがなく、どれも他のものより優れているわけではありません. ただし、コマンド ルーティングがより複雑になると (特に DataTemplates が関係する場合)、CommandSink バージョンが常に機能するとは限らないことに気付きました。
それらを組み合わせることもできます: DelegateCommand を使用し、さらに JoshSmith バージョンを使用すると、両方の利点を組み合わせることができます。必要なのはいくつかのヘルパー クラスだけです。実装はそれほど難しくありません。
それよりもはるかに重要なのは、アプリケーションの一貫性です。使用するものを決定したら、アプリケーション全体でこの方法に従う必要があります。
考慮すべき 2 つのポイント:
CommandSinkCommand や SimpleCommand (Cinch から) など、さまざまな MVVM フレームワークによって提供されるコマンドは、通常の ICommand と同じように機能します。特に、CanExecute ハンドラーは、UI の変更を引き起こす可能性のある何かが発生したと WPF が判断するたびに評価されます。を介して手動でこれを強制することもできますCommandManager.InvalidateRequerySuggested()。
それとは対照的に、Prism の DelegateCommands<> は、手動でコマンドを呼び出さない限り、CanExecute ハンドラーを呼び出しませんRaiseCanExecuteChanged()。コマンドが正常に再クエリされたときにも起動されるようにこれを変更する場合は、http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338 のコードを参照してください。
編集：
2 番目のポイント: MVVM フレームワークのコマンドは、通常、コマンド パラメーターとしてオブジェクトを受け入れます。対照的に、Prism の DelegateCommands<> はより厳密に型指定されています (もちろん、必要に応じて DelegateCommands を使用することもできます)。