INotifyPropertyChanged usage outside data binding

Question

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.

Just out of curiosity: Why perform the changed call on a getter? — WaltiD, Sep 08 '11 at 12:31
Thanks for pointing that out, didn't mean to include that. I've updated the question. — mservidio, Sep 13 '11 at 04:14

Ritch Melton · Accepted Answer · 2011-09-08T12:48:36.950

6

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?

edited Sep 08 '11 at 12:48

answered Sep 08 '11 at 12:33

Ritch Melton

11,498
4
41
54

I'm leaning towards using regular events. I agree and thing strongly typed events would be nicer to work with. As I'm using a T4 code generation template, do you think it would be overkill to add a changed event for each property within my classes? – mservidio Sep 13 '11 at 13:29
@mservidio - I'm not familiar with T4, but I bet there's a clearer class behavior that you could update on rather than each property. – Ritch Melton Sep 13 '11 at 17:16

score 2 · Answer 2 · answered Sep 08 '11 at 12:29

2

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?

answered Sep 08 '11 at 12:29

Random Dev

51,810
9
92
119

score 1 · Answer 3 · answered Sep 08 '11 at 12:30

1

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.

answered Sep 08 '11 at 12:30

Saad Imran.

4,480
2
23
33

score 0 · Answer 4 · answered Sep 08 '11 at 12:32

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

score 0 · Answer 5 · answered Sep 08 '11 at 12:57

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).

score 0 · Answer 6 · answered Sep 08 '11 at 13:19

0

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

answered Sep 08 '11 at 13:19

Mohamed Abed

5,025
22
31

score 0 · Answer 7 · answered Sep 08 '11 at 13:42

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.

INotifyPropertyChanged usage outside data binding

7 Answers7