私は2つのクラスを持っています:
どちらもインターフェースを実装していINotifyPropertyChangedます。
MainViewModel は、ViewModelA オブジェクトの監視可能なコレクションを保持します。MainViewModel のプロパティ "Y" で PropertyChangeNotification をトリガーするには、ViewModelA クラスの特定のプロパティ "X" を変更する必要があります。
質問 1: これを実装するための一般的な方法は何ですか?
質問 2: ObservableCollection で CollectionChanged をリッスンし、イベント ハンドラーをアタッチ/削除すること (「X」プロパティが変更されたかどうかを確認し、変更された場合は「Y」プロパティ変更通知をトリガーする) は悪い習慣ですか? はいの場合、なぜですか？
問題を明確にするために、子ビュー モデル (または、特定のケースでは子ビュー モデルのコレクションの要素) のプロパティが変更されたときに、親ビュー モデルにコールバックしたいと考えています。
特定のケースでは、UI を更新するために、メイン ビュー モデルのプロパティを使用して INotifyPropertyChanged イベントを呼び出します。
基本的に、Observer Design Patternの派生物を見ています。これにより、子ビューモデルの変更を何らかの形で「リッスン」し、親に通知されます。このパターンの 2 つの実装がすぐに利用できるように存在します。
イベント: 他の誰かがこの質問で既に回答しているように、子ビュー モデルでイベントを作成し、親から直接このイベントをサブスクライブできます。個人的には、可能な限りビュー モデルでイベントを定義することを避けています。私にとってビュー モデルはビューの論理的な表現であり、ビュー モデル インターフェイスでパブリック イベントを使用することは、粒度に反するようです。
イベント アグリゲーター:イベント アグリゲーター(PRISM によって提供されるものなど) を 使用すると、子ビュー モデルから起動される親ビュー モデルでメッセージをサブスクライブできます。子ビュー モデルにパブリック イベントを定義する必要がないことに対する代償は、 の実装への依存ですIEventAggregator。親ビュー モデルと子ビュー モデルの懸念事項と、それらの間の相互作用を分離するため、このアプローチが気に入っています。イベント アグリゲーターの使用は悪用される可能性があり、不注意に使用すると、アプリケーションで飛び交うすべてのメッセージを追跡するのが難しくなる可能性があるという警告があります。