ViewModel クラスはどの程度再利用可能であるべきでしょうか?

Question

私は WPF アプリケーションに取り組んでおり、MVVM パターンを使用してそれを構築しています。当初、ViewModel は再利用可能であるべきだという考えがありましたが、今ではあまり確信が持てなくなりました。

• WinForms アプリケーションに同様の機能が必要な場合、ViewModel を再利用できる必要がありますか?
• Silverlight は WPF が行うすべての機能をサポートしているわけではありません。Silverlight アプリケーションで再利用できる必要がありますか?
• 自分のアプリケーション用に Linux GUI を作成したい場合はどうすればよいでしょうか。次に、Mono で構築するために ViewModel が必要になりますが、これは私が努力すべきことでしょうか?
• 等々..

それで;1 つの特定のビューを念頭に置いて ViewModel クラスを作成する必要がありますか、それとも再利用性を考慮する必要がありますか?

Answer 1

あなたの質問に答えるために、単一責任の原則について考えます：

  

「クラスが1を持っている、とだけ必要があります   変更する一つの理由。」

私は合理的な範囲で、あなたは通常、複数のビューのためのViewModelを再利用したくない、と思います。それはあなたのViewModelに変更するには、複数の理由を与えるだろうので、私はこれを主張したい主な理由は、あります。言い換えれば、それはどちらか一方のビューが変更された場合に変更する必要があるだろう、と私の意見では、それは変更するには2つの理由があります。それはどこに停止していますか？私は、この場合にはそれをシンプルに保つ、およびビューに1つのViewModelにバインド思います。

WPFとMVVMと考えるべきもう一つは、データテンプレートです。それぞれのViewModelは1と1つのビューのみに食料調達する場合、それは達成するためにはるかに簡単です。

Answer 2

ただ、一般的には、YAGNIのprinciplを適用する - あなたは、おそらくそれを必要とするつもりはありません。あなたが潜在的に起こってこれらのものを見ることができない限り、私はあなたが現在持っている要件のために働いて、あなたのソフトウェアを入手する最も簡単な方法で続けると思います。

Answer 3

私の心の中では、 MVVM の主な目的は、単体テストでは簡単にテストできないコードを排除することです。. 。ビューモデルは単体テストできますが、ビューは単体テストできないため、これはビューを可能な限りダムにすることで実現されます。理想的には、XAML で実行できるように、ビューは完全に宣言型であり、ビュー モデル上でのみデータ バインドされます。したがって、「背後にコードはありません」という信条があります。

さまざまな UI テクノロジ間でのビュー モデルの再利用可能性は、MVVM の実際の目標ではありません。これを試してみると、ビュー モデルを再利用できるようにするために、UI テクノロジに固有のコードを再度ビューに移動したくなるでしょう。これはテスト容易性という主な目的に反します。

さまざまな UI テクノロジをサポートする必要があることが本当に必要な場合は、ビュー モデルの共通ロジックを共有の「プレゼンテーション」層に取り出すことができます。ただし、それが必要であると確信するまではそうしません。

Answer 4

この古い質問ですので、私は別の答えを追加することを躊躇します。しかし、これまでに投稿されたすべての答えは、ポイントを逃しています。 MSDNするからの答えは非常に明確です：ビューモデルは、非常に特にこの図に示されているように、種々のOSを横切って多くのビューで共有されることが意図されている

" ここに画像の説明を入力する

それ以外の場合は行うことは、必然的に冗長なコードにつながります。