巨大な「メインビューモデル」を作成しないでください。これは、神オブジェクトと似ていないアンチパターンです。
ここでの重要なアイデアは、ビューモデルが他のビューモデルからいくつかのプロパティにアクセスする必要がないということです。むしろ、すべてのビューモデルは特定の情報にアクセスする必要があります。
現在、インスタンス化時にこの情報を各ビューモデルに挿入している可能性があります。これを行う代わりに、各ビューモデルにサービスへの参照を提供します。これは、プロパティやメソッドを通じてこの情報を公開するアプリケーションモジュールです。情報は、本質的に非常に単純な場合はスカラー値の形式で、それよりも複雑な場合はモデルの形式で公開できます。
概略的には、これは次のようになります。
/--------------\
| ViewModelA |
| | <=======\
| | |
\--------------/ | <--- information is pulled /================\
+=========[model]===[model]====== | Service |
/--------------\ | \================/
| ViewModelB | |
| | <=======/
| |
\--------------/
サービスは、構築時にビューモデルに注入する必要があります(手動で、またはDIコンテナーを使用している場合はDIコンテナーによって)。各ビューモデルは、サービスへの参照と、関心のあるモデルをサービスに伝えるのに十分な情報のみを必要とします。次に、サービスにそのモデルを要求し、それに基づいて「興味深い」プロパティを設定します。
この方法は、単にビューモデルオブジェクトを作成してそのプロパティを外部に設定するよりも複雑ですが、アプリケーションを管理不能にすることなく複雑にすることができます。
たとえば、さまざまなビューモデルにバインドするビューが多数あり、これらのビューモデルが複雑な方法で多数のモデルに依存している場合、正常に機能するには次のようになります。
- ビュー/ビューモデルのペアが作成されます
- ビューモデルは、サービスから知る必要のあるモデルを要求します。モデルが変更されたことをサブスクライバーに通知するためにサービスが公開するイベントをサブスクライブします
- 変更は、データバインドされたコントロールを介してモデルに実行されます
- ビューは、ビューモデルで「保存」コマンドを呼び出します
- これに応じて、ビューモデルはサービスで「このモデルを保存」メソッドを呼び出します
- サービスは情報を保持し、「モデル変更」イベントを公開します(ステップ2を参照)。
- 同じモデルに関心のある他のビューモデルは、モデルが変更されたことを認識しており、サービスに新しい状態を問い合わせることができます
これは、すべてがサービスを介してルーティングされる場合に可能です。それ以外の場合はすべての同期を維持するために必要なことを想像してください。対処する唯一の方法は、すべての情報を巨大なビューモデルに入れ、他のすべてからそれを参照することです。ぶさいくな。