私は WPF アプリケーションに取り組んでおり、MVVM パターンを使用して構造化しています。当初、ViewModel は再利用可能であるべきだと考えていましたが、今ではよくわかりません。
そう; 1 つの特定の View を念頭に置いて ViewModel クラスを作成する必要がありますか、それとも再利用性を考えるべきですか?
あなたの質問に答えるために、単一責任の原則について考えてください。
「クラスには、変更する理由が1つだけあるはずです。」
当然のことながら、通常、ViewModelを複数のビューに再利用することは望ましくありません。私がこれについて議論する主な理由は、それがあなたのViewModelに変更する複数の理由を与えるからです。言い換えれば、どちらか一方のビューが変更された場合は変更する必要があり、私の意見では、それが変更する2つの理由です。どこで止まりますか？この場合は単純にして、1つのViewModelをビューにバインドします。
WPFを使用したMVVMで考慮すべきもう1つのことは、データテンプレートです。各ViewModelが1つのビューのみに対応している場合は、はるかに簡単に実行できます。
一般的には、YAGNI の原則を適用してください。おそらく必要ないでしょう。これらのことが潜在的に発生していると見なされない限り、現在の要件に合わせてソフトウェアを機能させるための最も単純なアプローチを採用します。
私の考えでは、MVVM の主な目標は、単体テストで簡単にテストできないコードを排除することです。ビュー モデルは単体テストできますが、ビューはできないため、これはビューを可能な限りダムにすることで実現されます。理想的には、XAML で実行できるように、ビューは完全に宣言型であり、ビュー モデルでのみデータ バインドします。したがって、「コードビハインドなし」のマントラです。
さまざまな UI テクノロジ間でのビュー モデルの再利用性は、実際には MVVM の目標ではありません。試してみると、ビュー モデルを再利用可能に保つために、UI テクノロジに固有のコードをビューに再度移動したくなるでしょう。これは、テスト容易性の主な目標に反します。
本当にさまざまな UI テクノロジをサポートする必要がある場合は、ビュー モデルの共通ロジックを共有の "プレゼンテーション" レイヤーに分割することができます。ただし、それが必要であることが確実になるまで、私はそれをしません。
これは古い質問なので、別の回答を追加することをためらっています。しかし、これまでに投稿されたすべての回答は要点を逃しています。 MSDN からの回答は非常に明確です。ViewModel は、次の図に示すように、さまざまな OS の多くのビューで共有されることを非常に明確に意図しています。
そうしないと、必然的にコードが冗長になります。