MVVMでは、ViewModelまたはViewが新しいビューの作成を担当する必要がありますか？

私のWPFアプリケーションで、新しいビューを作成します。ViewModelまたはModelのどこでそれを行うべきですか？

アプリケーションは（今のところ非常にシンプルです）、1つの「送信」ボタンを備えた1ウィンドウフォームのようなツールです。チェックボックスの1つが選択されている場合、同じViewModelを使用する新しいウィンドウがポップアップし、追加の詳細をユーザーに尋ねます。この質問の目的のために、表示/非表示のパネルなどの別のアプローチを考慮せずに、新しいウィンドウのアプローチのみを検討してみましょう。

理想的には、Viewにはコードがないはずです。さらに、Viewにはロジックが含まれていないため、VMは最初に新しいビューの作成が必要かどうかを確認する必要があり、必要な場合はこの責任をViewに戻して、コードの膨張につながります。

一方、ViewModelで新しいビューを作成すると、ViewModelがViewについて何も認識してはならないという原則に違反します。

では、ViewまたはViewModelで新しいビューを作成する方が良いでしょうか？

依存関係注入とIViewFactoryビューモデルへの注入を使用して、両方の制約を尊重します。

ProductViewModel（例えば）を呼び出しthis.viewFactory.Show("Details", this)開くことProductDetailsViewとしてそれ自体でProductViewModel。で別のビューモデルに基づくビューを開くこともできthis.viewFactory.Show<ClientViewModel>()ます。

実装（実際には、WinForms、単純なWpf Windows、タブ付きのWpfシェルなどがいくつかあります）はStructureMap規則に基づいています。ビューは、IView<ProductViewModel>インターフェースを介してビューモデルを指定します。

したがって、ビューモデルはその役割（デフォルトビュー、詳細ビューなど）を除いてビューについて何も認識せず、ビューには別のビューを作成するコードが含まれていません。また、ビューモデルは、Wpfアセンブリを参照しない別のアセンブリにあります。

理論的な答え

がある場合ViewModel、化粧効果を持つアクション（マウスオーバーでアイテムをハイライト表示するなど）はの仕事ですがView、「実際の」効果を持つアクション（たとえば、新しいウィンドウのスポーン）はの仕事ですViewModel。

そのため、新しいウィンドウの作成はの仕事ですViewModel。ただし、ビューもも、ViewModelウィンドウを作成する方法を正確に知っているべきではありません。これは、その責任の一部ではなく、別のクラスに属しています。

新しいウィンドウの作成はの仕事であると主張することができますView。私はそうは思わないでしょうが、実際にそのコードをに配置しても世界の終わりではないため、そのような議論にはほとんど価値Viewがありません。またViewModel、後でコードをに移動するのもそれほど面倒ではありません。。重要な部分は、新しいウィンドウを作成するためのロジックが独立したクラス、通常はある種のWindowFactoryに含まれていることです。MVVM、MVP、MVCなどのポイントは、責任がほとんど明確に定義されていないクラスがあることです。そのため、、、または必要がない場合はView、責任を追加しないでください。ViewModelModel

GUIのようなものがあることに気づいていないModelため、ウィンドウの作成はに属しModelません。

実用的な答え

これは、「単一の「送信」ボタンを備えた1ウィンドウのフォームのようなツール」に関するものです。だからここに私の関連する答えのための恥知らずなプラグがあります：なぜMVVMを使うのですか？

その答えが言うことを要約すると：シンプルにしてください。ああ、そして上記の理論的な答えを覚えておいてください。単一のボタンウィンドウがより複雑になり始めたら実装します。