コマンドとMVVMの原則 - RelayCommands

Question

私はC＃、WPF、およびMVVMパターンで新しくなっています。この非常に長い記事で申し訳ありませんが、私はすべての私の理解のポイント（あるいは理解していないこと）を設定しようとしています。

WPFとMVVMパターンによって提供されるコマンドメカニズムで多くのテキストを勉強した後、私はこれらのものをどのように使用するかについて、私の心をまっすぐにしています。

私は、WPFに用意されているコマンドで、ビジュアルツリーのコンポーネントに保持されているコマンドロジックに複数の「呼び出しポイント」を定義できることを理解しています。コマンドが呼び出されると、コールは、コマンドロジックがどこにあるかを定義するCommandBindingを保持する要素に衝突するまで、ビジュアルツリー（コマンドターゲットまたはフォーカスされた要素から開始）を介してバブルします。

これは、ロジックや呼び出しポイントを最初に指定せずにパブリックコマンドを定義できるという点でいいですね。

また、ビューのViewModelはロジックを処理する必要がありますが、コマンドの基本WPF実装では、呼び出しがビジュアルツリーを介して呼び出しを処理するため、ビジュアル要素でしか処理できません。

この場合、ビューの要素（たとえばボタン）によって呼び出されるコマンドを、下位のViewModelのRelayCommandオブジェクトにバインドするときに、Josh SmithのRelayCommandなどのカスタム実装を使用できることがわかりました。

しかし、私たちがViewModelで参照されている実装を直接指定しているので、それが（WPFコマンドパターンの定義によって）どのようにコマンドであるかわかりません。この方法では、ロジックがどこに実装されているかを知らなくても、どこからでもコマンドを呼び出せるという利点がすべて失われます。この場合、なぜClickイベントハンドラを直接使用しないのですか？

誰かが私のどこに間違っているか説明できますか？ （最後まで投稿を読んでくれてありがとう！）

よろしくお願いします。 NR

Answer 1

しかし、その後、私たちは直接のViewModelで参照される実装を指定しているので、もはや（WPFの指揮パターンの定義による）、それは、コマンドの方法を見てはいけません。

これはまだコマンドであり、ICommandを実装していますが、もはやWPFに組み込まれているルーティング戦略を利用していません。これはコマンドですが、もはやRoutedCommandではありません。つまり、WPFのルーティングされたコマンドインフラストラクチャの元のコンセプトに従わないのですが、まだコマンドです。

この方法では、ロジックが実装されている場所を知らずにどこからでもコマンドを呼び出せるというメリットがすべて失われます。この場合、なぜClickイベントハンドラを直接使用しないのですか？

ロジックをビューから切り離してもメリットがあります。ビューは、これがどのように実装されているかを知る必要はなく、ViewModelはビューがどのようにトリガーするかを知らずにコマンドを実装できます。このコマンドは、ロジックやコードをまったく変更することなく、ジェスチャーやボタンなどから変更して（完全にXAML内で）変更することができます。

イベントハンドラに戻すと、イベントハンドラを使用する場合、ビューの実装を変更するにはイベントハンドラ（コードビハインド）を更新する必要があります。

Answer 2

MVVMプロジェクトで元のWPFコマンドの動作を使用する方法についてさらに調査したところ、このリンク：http://matthamilton.net/commandbindings-with-mvvm！

私が理解するところでは、viewmodelによって処理されるCommandBindingsビューに「添付」する方法を提供します。このようにして、ビューモデルは、コマンド呼び出しがビジュアルツリーを歩くときに発見されるコマンドバインディングを実装することができる。

Bye。