このタイプのクラス構造化にアプローチするための最良の方法
私の意見では、「最善の方法」の最も重要な手段は、アプリが機能することを意味する方法を選択することです。
あなたが見た例（スフェロボールコントロール）には、独立したビューモデル（ホーム、江南、アバウト、スフェロなど）の両方の例があり、お互いを知っているいくつかのビューモデルの例（スフェロビューモデル）がありますそしてそれはサブビューモデルです。
この特定のケースでは、これらのビューモデルがすべてお互いを知っている理由は、それらがすべて単一のディスプレイの一部であるためです。これらは、単一のグリッド、ピボット、またはタブ付きUI内に一緒に配置されるように設計されています。彼らの協力を支援するために、私はIParentおよびIChildインターフェースを介してそれらに相互参照を与えました。
これは、mvvmが推奨する分離されたビューモデルの逸脱ではありませんか？
これは、デザインが完全に分離されていないことを意味し、将来、それらの子vmを移動または再利用する必要がある場合は、コードのリファクタリングを少し行う必要があるかもしれませんが、今のところ、デザインはうまく機能しています、そして私は個人的に、必要に応じて将来そのリファクタリングを行うことができてうれしいです。
今の私の最大の関心事は、ビューモデル間でデータを共有し、同時にmvvmガイダンスに従うために、ビューモデルをどのように編成する必要があるかを決定することです。
複合（タブ付き）ビューを構築していて、集約されたビューモデル（sphero vmやそのサブビューなど）を使用することに満足できない場合は、使用しないでください。
1つの大きなビューモデルを使用するか、メッセンジャーを介して通信する複数のビューモデルを使用するか、1つ以上のカスタムサービスを介して通信する複数のビューモデルを使用することで、同じ効果がspheroで達成された可能性があります。
構成とメインビューの特定の例では、これはタブ付きのシナリオには当てはまらないと思います。おそらくメッセンジャーを使用してこれをコーディングします。これにより、変更通知をブロードキャストおよび受信するための柔軟なメカニズムが提供されます。アプリのさまざまな部分。
ただし、他のデザインは間違いなく利用可能で実行可能です。たとえば、表示されるたびにビューモデルに構成を更新するように簡単に依頼できます（これを行うには、onnavigatedto、viewwillapear、およびビューの再開呼び出しにフックする必要があります）。
要約すれば：
- 独立したビューモデルを作成し、サービスを介して通信させるというあなたの一般的な目標に同意します。
- メインページと設定ページの場合、おそらく2つの別々のVMとメッセンジャーを使用します
- タブ付き/ピボットUIの場合、私は個人的にその完璧なパラダイムから脱却しました-しかし、mvxにはあなたが私に従うことを強制するものは何もありません