MVVM ソリューションを構築するためのベスト プラクティスを理解したいと思います。
現在、View と ViewModel 用に別のプロジェクトを作成しました。私の View プロジェクトは、私の ViewModel プロジェクトを参照しています。ここまでは順調ですね。ナビゲーションの実装に関しては、ViewModel クラスはナビゲートするために RootFrame にアクセスする必要がありますが、RootFrame は View プロジェクトにある App.xaml にあります。したがって、ここには循環依存の問題があります。
使用すべき推奨構造はありますか? これをすべて 1 つの大きなプロジェクトにまとめることもできますが、View と ViewModel を切り離すには、別々のプロジェクトを作成する方がよいと思います。
ナビゲーションの実装に関しては、ViewModel クラスは RootFrame にアクセスする必要があります
これは誤った仮定です。
パブリッシャー (ViewModel) とサブスクライバー (ビューを開くのを担当するオブジェクト) の間でメッセージの配信を担当するメッセージ ブローカー (単一のオブジェクト) を使用できます。
ほとんどの MVVM フレームワークには、このようなブローカーがあります。
依存関係について
Broker の唯一の責任は、イベントを発生させることです。したがって、一般に、パブリッシャーが呼び出すことができるいくつかのメソッドと、サブスクライバーが登録できるいくつかのイベントを公開します。
MVVM では、このメカニズムを使用して、ビューを開く必要があることを通知するイベントを ViewModel に発生させ、このイベントをサブスクライブする View Manager を発生させることができます。View Manager は、View をインスタンス化し、正しい ViewModel をアタッチできる必要があります。
ViewManager がすべての View および ViewModel への参照を必要としないようにするには、イベントの論理名 (単なる文字列) に渡し、構成ファイルのリフレクションまたは静的リストを使用して、View Manager に一致する View(Model) タイプを検索させることができます。 .
この方法では、循環参照参照は必要ありません。実際、MVVM の適切な依存関係に反する参照が必要な場合は、まずセットアップを疑ってから、View や ViewModels の基本クラスの使用を検討する必要があります。
MVVM は誰もが好みに応じて異なる方法で実装する設計パターンであるため、MVVM のベスト プラクティスはありません。私はかなりの数の異なる実装を見てきましたが、ビューとビュー モデルを別々のプロジェクトで見たことはありません。それらを同じプロジェクト内の別のフォルダーに保持し、別の名前空間に配置することをお勧めします。
たとえば、ビュー モデルは ViewModels フォルダーに移動し、名前空間 MyProject.ViewModels に配置できます。
ビューは Views フォルダーに入れ、名前空間 MyProject.Views に入れることができます
モデルを使用している場合は、モデルについても同じです