Should our own code subscribe to PropertyChanged?

We have a number of data objects that realize INotifyPropertyChanged to allow for WPF Binding updates. There are also a number of places where our code subscribes to PropertyChanged because we're interested in some value updates.

This results in pretty ugly code where we need to check which property actually changed (we do this using Expressions so it's always type/refactor safe).

Is the preference to raise a specific event (PriceChanged etc...) for when we want to subscribe to it, or hook into PropertyChanged and check the property name?


If a number of properties you want to subscribe to is not very big, I'd create dedicated events as they are better in terms of readability and discoverability.

However, if there are quite a few properties the answer is not so obvious. I usually try to avoid such situations by applying Observer Synchronization pattern (subscribing to Model changes rather than ViewModel). It helps me keep VMs thin.

Need Your Help

Does a concurrent hashmap not require synchronized getters/setters?

java hashmap concurrenthashmap

If i was using a concurrent hashmap and i had methods which set and got values, as im using a concurrent hashmap would i need to make the getter and setter synchronized? Is this redundant? Is one d...

Deny workitem workflow editing

tfs tfs-power-tools

We are using tfs 2013 update 4.