私はいくつかの宿題をしましたが、各方法をいつ使用するかについてのベストプラクティスに関する記事を見つけることができませんでした..
明確にするために： イベントアグリゲーターパターンを使用する場合：各画面にはビューモデルの独自の参照があり、ビューモデルはイベントアグリゲーターを使用して変更を公開し、後でオブザーバーが状態を同期するために使用します。
ViewModel のキャッシング: すべての画面にはビューモデルの保存参照があり、ビューモデルのプロパティにバインドされているコントロールは同期されます。これは、アプリ内のすべての画面にビューモデルの同じ参照がある (キャッシュから取得した) ためです。画面はデータバインディングのおかげで同期されます。
各アプローチをいつ使用するか それらのそれぞれを使用することの長所と短所は何ですか?
共通データに適したもう 1 つのオプションは、同期が必要な複数のビューモデルでプロパティを複製するのではなく、必要なプロパティを公開する 単一のObserverクラスに直接バインドすることです。
オブザーバーの使用は、イベント アグリゲーターへのサブスクライブ/パブリッシュよりも結合されていますが、オブザーバー インターフェイスが IOC コンテナーを使用して挿入される場合、結合は依然としてかなり緩いままであり、どのビューモデルがどのオブザーバーに依存しているかを非常に簡単に判断できます。
私が見ているように、イベント アグリゲーターのアプローチはよりスケーラブルであり、より分離された設計を提供します。
単一の VM (または複数の VM のキャッシュ) アプローチは、スケーラビリティが問題にならない場合に適しています。ビューが追加されるにつれて VM が巨大な比率に成長する可能性があるからです。
要約すると、イベント アグリゲーター アプローチは、持続するように構築されたシステムの「正しい」アプローチですが、特定の限られた目的と有効期間のために内部ツールを構築している場合は、より単純なアプローチを使用できます。
早速のお返事ありがとうございます！あなたが言っていることは、同じ VM クラスが複数の画面に使用され、それぞれのコントラクトを満たす場合にのみ当てはまります (この状況では、VM にバインドする一部の画面では使用されない冗長フィールドが含まれている可能性があります) ）。
しかし、この状況は、より粒度の高いアプローチを使用してコンポジションを使用すると簡単に修正できます...
ところで、イベントアグリゲーターがより分離されていることに同意します...他に考慮すべきことはありますか?