MVVMでは、ViewModelまたはViewが新しいビューの作成を担当する必要がありますか？
私のWPFアプリケーションで、新しいビューを作成します。 ViewModelまたはModelのどこでそれを行うべきですか？
アプリケーションは（今のところ非常にシンプルです）、1つの「送信」ボタンを備えた1ウィンドウフォームのようなツールです。チェックボックスの1つが選択されている場合、同じViewModelを使用する新しいウィンドウがポップアップし、追加の詳細をユーザーに尋ねます。 この質問の目的のために、表示/非表示のパネルなどの別のアプローチを考慮せずに、新しいウィンドウのアプローチのみを検討してみましょう。
理想的には、Viewにはコードがないはずです。さらに、ビューにはロジックがないため、VMは、最初に新しいビューの作成が必要かどうかを確認する必要があり、-必要な場合は-この責任をビューに戻して、コードを作成します。膨満。
一方、ViewModelで新しいビューを作成すると、ViewModelがViewについて何も認識してはならないという原則に違反します。
したがって、ViewまたはViewModelで新しいビューを作成する方が良いですか？
依存性注入と、ビューモデルに注入されたIViewFactoryを使用して、両方の制約を尊重します。
ProductViewModel（たとえば）はthis.viewFactory.Show("Details", this)を呼び出して、ProductDetailsViewをProductViewModelとして開きます。また、this.viewFactory.Show<ClientViewModel>()を使用して、別のビューモデルに基づくビューを開くこともできます。
実装（実際には、WinForms、単純なWpf Windows、タブ付きのWpf Shellなどがあります）は、StructureMap規則に基づいています。ビューは、IView<ProductViewModel>インターフェースを介してビューモデルを指定します。
そのため、ビューモデルはその役割（デフォルトビュー、詳細ビューなど）を除いてビューについて何も認識せず、ビューには別のビューを作成するコードが含まれていません。また、ビューモデルは、Wpfアセンブリを参照しない別のアセンブリにあります。
理論的な答え
ViewModelがある場合、化粧効果を持つアクション（マウスオーバーでアイテムを強調表示するなど）はViewの仕事ですが、「本当の」効果を持つアクション（新しいウィンドウの生成など）は）はViewModelの仕事です。
そのため、新しいウィンドウの作成はViewModelの仕事です。ただし、ビューもViewModelも、ウィンドウの作成方法を正確に知る必要はありません。これは、それらの責任の一部ではなく、別のクラスに属しています。
新しいウィンドウを作成することはViewの仕事であると主張できます。私はそうは思わないでしょうが、そのような議論にはほとんど価値がありません。なぜなら、実際にそのコードをViewに配置することは世界の終わりではなく、それを移動するのもそれほど面倒ではないからです。後でViewModelに。重要な部分は、新しいウィンドウを作成するためのロジックが独立したクラス、通常はある種のWindowFactoryに含まれていることです。 MVVM、MVP、MVCなどのポイントは、責任がほとんど明確に定義されていないクラスがあることです。そのため、必要がなければ、View、ViewModel、またはModelに責任を追加しないでください。
ModelはGUIのようなものがあることさえ認識していないため、ウィンドウの作成はModelに属しません。
実用的な答え
これは、「単一の「送信」ボタンを備えた1ウィンドウのフォームのようなツール」についてです。だからここに私の関連する答えのための恥知らずなプラグがあります： なぜMVVMを使うのですか？
その答えが言うことを要約すると：シンプルにしてください。ああ、そして上記の理論的な答えを覚えておいてください。単一のボタンウィンドウがより複雑になり始めたら実装します。