tags:

views:

214

answers:

2

I'm designing a new class in C# which has a few properties. My users will want to know when each of them changes.

What's a better choice? INotifyPropertyChanged style of implementation, or just having separate events corresponding to my properties? Or both?

+4  A: 

Going forward, INotifyPropertyChanged is the norm, and has much better support in WPF. I seem to recall that BindingList<T> only respects INotifyPropertyChanged (see HookPropertyChanged and UnhookPropertyChanged in reflector).

This is also more efficient, as the UI only needs one event hook, rather than one per event - and your class can be more efficient as it only needs a field for one handler (rather than either one per property, or the niggle of having to go via EventHandlerList and a set of static keys)

The old style is mainly a hangover.

Marc Gravell
Thanks, I fixed the interface name.
Filip
But can you see yourself using this? I mean, are you expected to do a string comparison to figure out what changed?
Filip
Yes, basically. Or compare against UI controls which will commonly have a mapping name that is a string.
Marc Gravell
+2  A: 

Implementing the INotifyPropertyChanged interface will give you the added benefit of having binding sources automatically listening to changes you make to your properties and updating the controls.

Try doing this. Create a class without the INotifyPropertyChanged interface and bind it to something. For instance you can bind one of its properties to the Text property of a TextBox. Add a button that will change, not the text of the TextBox, but the value of the respective property in the instance that is bound to the box. Run and click the button. The textbox will not be notified of the change. If you then implement the INotifyPropertyChanged in the class, have the property's setter notify of its change via the PropertyChanged even, after you repeat the experiment, you'll see the TextBox updating.

Rui Craveiro