変更を追跡するビューモデルが必要なので、ユーザーは編集やロールバック部分に応じて物事が視覚的に変化するのを見ることができます。現在、ビュー モデルのコンストラクターの最後のステップとして、変更の追跡を「オン」にしています (ビュー モデルがテンプレートから構築されている場合やPropertyChanged、構築が完了する前にトリガーされるデフォルト ロジックを持っている場合があるため、必要です)。ユーザーが何かを行う前であっても変更されます)。
これで大体はうまくいきましたが、
変更の追跡を有効にするより良い場所はありますか?
理想的な MVVM の実装では、ビューがビュー モデルといつ、どのように通信するかがわからない可能性が高いため、より優れた場所や代替の場所はありません。実際、ビュー モデルはビューについて何も認識すべきではありません。ビューは、Silverlight UI やコンソール アプリ、テスト モックアップなどです。一般的な考えによれば、コンストラクターは「変更追跡」を無効にする唯一の場所のようです。
MVVM に厳密に従おうとする場合は、ビュー モデルをメイン オブジェクトとして、ビュー モデルをセカンダリ オブジェクトとして受け入れる必要があります。つまり、特定のビューの実装に関係のないロジックをビューに導入するべきではありません。現在のビュー モデルの状態を表示し、ユーザーのアクションをビュー モデルに伝えるだけです。true の場合、コンストラクター以外の場所で変更追跡をオフにする必要はありません。
もちろん、現実の世界では、これに従うのはかなり難しくなるかもしれません。別の解決策が見つからない場合は、ビュー モデルに追加のプロパティを導入できます。たとえばIsViewInitialized、「変更の追跡」を有効にし、必要に応じてビューにプロパティを設定します。
しかし、これはできるだけ避けたほうがよいでしょう。このようなアプローチは、MVVM パターンの主要なアイデアの 1 つに反する View と ViewModel の間の結合を増加させます。
個人的に私に尋ねると、私のビュー モデルには初期化ステップの代替ロジックがほとんどありません。また、通常は「変更追跡を無効にする」ことはせず、いくつかのフィールドを直接設定して、ほとんどの場合プロパティ セッターに存在する通常の変更追跡コードを回避します。ただし、コンストラクター内であっても、一部のプロパティに対してそのロジックをトリガーする方が便利な場合があります。
一般に、変更の追跡を処理する「正しい」または「間違った」場所はありません。
ただし、VM 内で実行したい場合は、RaisePropertyChanged() メソッドで、変更されたプロパティのリスト (changesList) を蓄積できます。このリストをクリアしてデータを保存するパブリック (おそらく仮想) メソッド ApplyChanges() を実装する必要があります (ネットワーク経由で変更を投稿する場合は、同じデータを何度も送信しないようにチェックを追加します)。また、パブリック プロパティ bool IsChanged { get; }、これは changesList.Any() を返します -- このプロパティを使用して、「適用」ボタンをバインドできます。
あなたの場合: 複雑なコンストラクターでは、ApplyChanges() を呼び出して IsChanged 状態をリセットし、複雑なコントロールが VM にバインドされた後、ApplyChanges() も呼び出します - ユーザーがまだ何もしていないことがわかっている場合でも。