複雑なMVVMのヘルプ（複数のビュー）

次のシナリオのビューモデルの作成にヘルプが必要です。

1. 深い階層データ
2. 同じデータセットの複数のビュー
3. 各ビューは、アクティブな選択に基づいて、動的に変化する単一のビューです
4. プロパティの値に応じて、タブコントロールにさまざまな種類のタブを表示する

私の質問：

各ビュー（VM1、VM2など）のビューモデル表現を作成する必要がありますか？

1. Yes:
    a. Should I model the entire hierarchical relationship? (ie, SubVM1, HouseVM1, RoomVM1)
    b. How do I keep all hierarchies in sync? (e.g, adding/removing nodes)

2. No:
    a. Do I use a huge, single view model that caters for all views?

これが単一のビューの例です

図1：アクティブルームに基づいて更新された複数のビュー。通知タブコントロール

図2：別のアクティブルーム。複数のビューが更新されました。オブジェクトのプロパティに基づいて変更されたタブコントロール項目。

図3：別の選択タイプ。ビュー全体の変更

質問に答えるには、はい、各ビューには独自のビューモデルが必要です。ただし、階層全体をモデル化する必要はありません。ビューに必要なもののみ。

MVVMに関するほとんどのオンラインリソースで発生した問題：

ほとんどの例では、ビューはモデルのほぼ1対1のマッピングです。しかし、同じモデルのさまざまなファセットにさまざまなビューが存在する私のシナリオでは、2つの選択肢の間で立ち往生しています。

他のすべてのビューモデルで使用される1つのモノリシックビューモデル

または、各ビューに1つのビューモデル

しかし、両方とも理想的ではありません。

モデル指向のビューモデル（MVM）は、コードの重複は少ないですが、維持するのは悪夢です

ビュー指向ビューモデル（VVM）は、各ビューに対して高度に専門化されたクラスを生成しますが、重複を含みます。

最終的に、Viewごとに1つのVMを保持する方が保守とコーディングが簡単であると判断したため、VVMアプローチを採用しました。

コードが機能したら、すべての一般的なプロパティと操作を現在の最終形式にリファクタリングし始めました。

この最終形式では、共通ビューモデルクラスが各VVMに構成されます。

もちろん、私はまだ一般的/専門と見なされるものを決定する必要があります。また、ビューが追加/マージ/削除されると、このバランスが変化します。

しかし、これの良いところは、メンバーを共通からVVMへ、またはその逆に簡単にプッシュ/ダウンできるようになったことです。

そして、オブジェクトの同期を保つことに関する簡単なメモ：

共通ビューモデルを持つことで、このほとんどが処理されます。各VVMは、単純に同じ共通ビューモデルへの参照を持つことができます。

また、単純なコールバックメソッドから始め、複数のリスナーの必要性が生じた場合はイベント/オブザーバーに進化する傾向があります。

そして、本当に複雑なイベント（つまり、予期しないカスケード更新）の場合、メディエーターの使用に切り替えます。

子が親への後方参照を持っているコードを敬遠しません。コードを機能させるためのあらゆるもの。

そして、リファクタリングの機会が生じた場合、私はそれを取るでしょう。

私が学んだ教訓：

1. glyい/作業コード>美しい/非作業コード
2. 巨大なクラスを分割するよりも、複数の小さなクラスをマージする方が簡単です

モックアップを見ると、ViewModelの階層と多数の小さなビューを作成することをお勧めします。そして、おそらく元の階層のかなりの部分をモデル化する必要があります。

ViewModel間の同期を維持するには、いずれかのイベントを使用するか、ViewModel間で相互にプロパティを設定します。ビューとViewModel間の同期は、標準の通知プロパティである必要があります。