问题
I recently find out that wpf handles INotifyPropertyChanged in two different ways. I just wanna know what's the reason.
Let us take a normal twoway binding with validation true.
if you set a property from ui to viewmodel it goes like this.
- setter call started
- value set
- INotifyPropertyChanged started
- INotifyPropertyChanged done
- setter done
- getter called and done
- IDataErrorInfo called and done
but if you set the property in your viewmodel it goes like this
- setter call started
- value set
- INotifyPropertyChanged started
- getter called and done
- IDataErrorInfo called and done
- INotifyPropertyChanged done
- setter done
回答1:
Changing property from UI to ViewModel may lead to deadlock kind of situation which might run into end less recursive calls in two way scenarios. In order to block this from happening, when WPF is making change to model, it will continue to track changes via INotifyPropertyChanged ,but this change will be queued in dispatcher queue, and it will be executed after its current update is finished.
Since the change in viewmodel is not initiated by WPF, WPF will not queue the operation, it will immediately execute the change.
来源：https://stackoverflow.com/questions/10947380/why-wpf-binding-handles-inotifypropertychanged-in-two-different-ways