wpf - 意味的には、コマンドとコンバーターをビューまたはビューモデルに近づける必要がありますか？

Question

MVVMで、コンバーターとコマンドをビューまたはビューモデルに近づけるように設計する必要があるかどうか疑問に思っています。コンポーネント間のギャップを埋める2種類の接着剤オブジェクトであるため、私にとってはグレーゾーンです。たぶんそれは本当に問題ではありませんが、StackOverflowがそれについて何を言っているのか疑問に思っています。

コンバーターは、ビューが変更されても再利用できることが多いため、以前はViewModel名前空間に配置していました。ただし、ビューの近くにコメントを配置するコメントが増えています。トップアンサーを参照してください：
ViewModelはXAML要素をプロパティとして公開する必要がありますか？
WPFコンバーターをMVVMパターンでどのように使用できますか？

コマンドは通常、UIイベントを実装するためにViewModelによって公開されるため、ViewModel名前空間にもコマンドを配置しました。典型的な例はRelayCommandsです。次に、コマンドを使用してメインビューとViewModelの間のダイアログを表示する興味深いパターンに出くわしました。私はそれがその単純さによってちょうど素晴らしいと思います。コマンドは実際には単なるプロキシですが、明らかにUIランドにあります。賛成か反対か？参照：
MVVMおよびMVVMを
使用したWPFでのダイアログの処理

では、コマンドとコンバーターはMVVMのどこにあるべきだと思いますか？意見？ViewModel？関係ない？

Answer 1

彼らがどちらかの陣営にいるとは言えないと思います。あなたが言ったように、それらの目的は、ViewModelとViewの間のブリッジを作成し、それらを分離したままにすることです。そして私の意見では、それはあなたがそれらをグルーコードとして扱うべき方法です。

コンバーター-xamlコントロールに簡単にバインドして表示するために情報をどのように適応させるかに責任があるため、コンバーターはビューに近いと主張できます。

さらに、理論的には、表示方法に応じて、同じViewModelプロパティに対して2つの異なるコンバーターを使用できます。

しかし、必要が生じた場合、ビューがまったく関与していない場所で、他のコンテキストでそれらを使用することを妨げるものは何もありません。

あなたの質問はそれらをどこに置くかも暗示しているので、再利用を容易にするために、コンバーターをviewsフォルダーにもViewModelsフォルダーにも別々に置きました。

コマンド-通常、MVVMのViewModelによって公開されるため、ViewModelに近いという議論になる可能性がありますが、私の経験では、Bindingsを介してViewModelからロジックを呼び出すのを容易にするために最も頻繁に使用されます。単純なケースでは、ViewModelメソッド呼び出しをxamlで直接バインドできれば、コマンドは使用しなくなります。

通常はViewModelにバインドされていますが、コマンドはViewsとViewModelsの間で再利用できる場合もあります。コマンドのコードをコピーして貼り付ける場合は、コマンドを分離し、ViewModelをインターフェイスの背後に配置して再利用できます。

さらに、コマンドパターンには、MVVMの範囲外で多くの用途があります。（たとえば、アプリケーションロジックで使用して、「元に戻す」機能を容易にすることができます）

それらを配置する場所については、通常、ViewModelに配置することから始め、状況が複雑になるにつれて、必要に応じて移動します。物事が複雑になったときに何ができるかについての興味深い投稿があります：ViewModelでコマンドの乱雑さを回避するにはどうすればよいですか？

これは主観的な答えだと思いますが、良い議論ができたと思いますし、意見を受け付けています。