複雑なMVVMアプリケーションでビューモデルを構築する方法
WPF MVVMアプリケーションの設計に苦労しています。私が取ったいくつかのコースでは、コンストラクターに多くのパラメーターを持つことはコードの匂いだと彼らは言っていますが、彼らはそれに対処する方法については決して触れていません。
私の最近のプロジェクトでは、依存関係注入を使用して、データアダプターパターンに従うサービスを提供しました。これらの各クラスは、ベンダー、従業員、詳細、見積もり、見積もり依頼などのタイプに焦点を当てています。
このアプリケーションでは、高レベルのビューモデルはあまり機能しませんが、詳細、添付ファイル、メモ、ベンダーの選択、ベンダーの要件など、いくつかのビューモデルをホストします。未処理の詳細ビューモデルのコンストラクターは、コンストラクター内のほぼすべてのサービスを取得しますが、それらのパラメーターを使用して子ビューモデルを構築します。
メインビューモデルはトップレベルのナビゲーションのみを担当するため、メインビューモデルが詳細ビューモデルについて知っていることは意味がありません。では、多くのコンストラクタパラメータなしで高レベルのビューモデルを作成するためにどのようなアプローチを使用できますか、または高レベルのビューモデルが低レベルのビューモデルの構成を担当しているため、この場合は悪い習慣ではありませんか？
私たちのチームは、ASP.NET MVCフレームワークのビューモデルで同じ問題を抱えていました。ビュー階層の構成が複雑になり始め、ユーザーインターフェイスが進化するにつれ、ビューモデルの構造を次々と変更し、コンストラクターの引数を渡すことで、これらの変更をさらに下に伝達しなければなりませんでした。
Webページ全体を表すビューモデルには、複数のソースからの多くの情報が本当に必要であることに気づきました。それでも、複数のコンテキストでビューモデルを再利用することができましたが、構成が少し異なっています。
これらの「トップレベル」のビューモデルは実際にはアプリケーションのユースケースを表し、Webページの一部を表すビューモデル（個々のコンポーネント）とは異なる初期化ニーズがあることに気付きました。
複雑なビューモデルの初期化に特化したビューモデルファクトリオブジェクトを導入しました。画面上の単一のコンポーネントを表すビューモデルは依存関係が少なく、コンストラクターパラメーターを使用してそれらの初期化を続行できました。
「ビューモデルファクトリーが必要です！」と言ったところで、明確な境界線がありませんでした。直感になった。ビューモデルの初期化が複雑になると、初期化ロジックをファクトリメソッドに移動しましたが、ビューモデルの初期化は、その時点に到達するまで、各ビューモデルのコンストラクターが行います。