Reputation: 3476
I've been using the following bit of code in a cookie cutter fashion, across dozens of classes
public event PropertyChangedEventHandler PropertyChanged;
protected void NotifyPropertyChanged(string propertyName)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
All of these classes implement INotifyPropertyChanged
. To silence my DRY alarms, lately I've been refactoring these classes to inherit my base class PropertyNotifier
whose only purpose is to provide NotifyPropertyChanged
for classes that inherit from it -- which are the dozens of ViewModel
classes in my huge project.
It feels lazy and a bit dirty. Am I hurting performance or breaking good design practices? I figure if change notification was supposed to be this easy, there would be a base class already in the WPF framework that does what my PropertyNotifier
class does.
Note that, for a lot of reasons, I've been having performance issues with my UI responsiveness -- mostly due to a large number of controls. So I'm looking to trim the fat wherever I can. Any ideas?
Upvotes: 7
Views: 2598
Reputation: 15802
Yes, that's very common practice. For a large scale application it becomes necessary to have this kind of base class. We had also created a BaseViewModel
for the same purpose; we also implemented a lot of common code(across ViewModels) in this base class like logging, displaying error messages, initializing WCF proxy objects etc.
Upvotes: 3
Reputation: 7031
Another implementation is the Model class of the WPF Application Framework (WAF). It does exactly the same.
Upvotes: 2
Reputation: 16129
This is a very common base class to have in WPF or Silverlight development and won't noticeably affect performance. The only problem I have with PropertyNotifier
as a base class results from being restricted to single inheritance but that tends to be a rare issue with the type of class you'll need it for.
Upvotes: 5