INotifyPropertyChanged usage outside data binding

I've never used INotifyPropertyChanged, and I'm considering using it widely throughout a new application.

My question is, is it 'proper' to use INotifyPropertyChanged interface in order to provide event notifications for things other than databound controls?

It seems from a bunch of examples online that this interface is widely used for notifying grids and such for when data is changed.开发者_运维技巧 I have various scenario's where I need other classes to be notified of data changes in other classes, and I was wondering if you think it's cleaner to implement this interface, and perform the changed call on setters, or rather just create regular events.

When making a choice like this, I lean towards using language features over other constructs.

A severe downside to INotifyPropertyChanged is that it only provides the property name as a string on update, and your consuming classes have to parse that string and decide how to act on it.

With events you can provide any kind of delegate signature that the event requires and the consuming classes can act on that change directly.

If you peek under the hood, you'll find that INotifyPropertyChanged is an event anyway, so why not use events directly?

I think you can use this Interface for those scenarios but you have to really think hard about if you want this thight coupeling between your classes. If this makes sense to you - sure, why reinvent the wheel?

I think you should go ahead an implement the INotifyPropertyChanged interface, just because it's there for that purpose and its what the UI uses to pickup changes, there's no need to create custom events yourself.

WPF and Silverlight both use INotifyPropertyChanged extensively in the data binding system. If your are going to databind to your objects, you should definetely use INotifyPropertyChanged. |

Otherwise, as far as I know, it does not influence .NET Framework technologies.

INotifyPropertyChanged is not the cleanest way of notifying when your property changes, depending on how you look at it, since there is one event and a string with the propertyname, you will have to make a switch statement. It sure is easier to implement comparing to events per property though

I would not use INotifyPropertyChanged for anything except databinding. This interface is probably the only option for databinding because controls which will act on PropertyChanged event do not know sender's type in advance. Because of that databinding has to use such a generic interface.

For my own types and scenarios I would use regular events (one event per each property which can change its value). INotifyPropertyChanged in such scenarios is kind of stringly typed code. You can see that even WPF itself is still full of oldscool events (FrameworkElement for example with a lot of ***Changed events).

Dont use is in other scenarios, if you need to notify other domain classes use domain events instead, which would be more business oriented and descriptive and strongly typed

I am not a fan of INPC outside of the UI realms as it hides the fact that significant events are being generated by instances of the object. Also, if I use your class implementing INPC, I will expect all properties to broadcast notifications, if only some of them do, that's a bug at runtime that can go unnoticed.