Is implementing INotifyPropertyChanged on a custom control a bad practice?

Question

Imagine a Control is being created.

It has some DependencyProperties and there are some properties which depend on the DependencyProperties, but doesn't need to be seen or updated from the outside.

---

For example: Foo is a DependencyProperty (that can be both read and write from the outside) and Bar is a common property that will be updated when (and only when) Foo changes.

public class MyControl : Control
{
    private static DependencyProperty FooProperty = 
        DependencyProperty.Register("Foo", 
                                    typeof(int), 
                                    typeof(MyControl), 
                                    new PropertyMetadata(FooChanged));

    private static void FooChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        MyControl changedObject = d as MyControl;

        changedObject.Bar++;
    }

    // The dependency property
    public int Foo { get; set; }

    // The property that is changed (only) when the dependency property changes
    public int Bar { get; private set; }
}

However, Bar's value is displayed in the screen (a Binding is established in the control's template). But since Bar is not a DependencyProperty no notification is sent to say that it's value has changed.

I see two options to solve this issue (but I'm open to suggestions).

1. Make my Control implement INotifyPropertyChanged

or

2. Make Bar a readonly DependencyProperty

---

What are the pros and cons of each approach? How should I proceed?

Is it a bad practice to implement INotifyPropertyChanged on a Control?

@EDIT

This questions was raised when I was creating a control that filters and displays a collection of games.

The data of this collection is "constant" (the games are loaded with the app and doesn't change to the end of the execution). However, the user can apply filters to this collection (for example, only displaying games that are in English)

As you can imagine, the filters are the Dependency Properties, while the collection of games is a simple property, that I wasn't sure if I should turn into a ´DependencyProperty´ (since it would always be the same, only filtered according to the ComboBoxes)

Answer 1

Your edit seems to change the perspective on things. The bottom line is that if you want the UI to react to changes in your control, you have to tell it that things changed. Based on a few years of WPF work, I've developed a few guidelines:

Collections

Use ObservableCollection as your type. They notify the UI when values are added and removed.

Read-only properties can be simple properties:

public ObservableCollection Games { get; }

Otherwise use DependencyProperty and ObservableCollection together

public static DependencyProperty GamesProperty = DependencyProperty.Register(...);

public ObservableCollection Games
{
    get { return GetValue(GamesProperty) as ObservableCollection; }
    set { SetValue(GamesProperty, value); }
}

Properties on DependencyObjects (includes Controls)

Never bind to a simple property. There are old bugs in WPF that have not been fixed that cause memory leaks in this case. Make everything a DependencyProperty.

DependencyObjects have their own set of rules, so any property used in the interaction really needs to be a DependencyProperty. It's a pain in the butt, but it will save you headaches later.

Properties on Models/ViewModels

Anything that you intend to update on screen needs to implement INotifyPropertyChanged. Those properties don't have the same memory leak as a simple property.

(More Information)

Answer 2

A Control is the View part of MVVM. What you are updating in a View is dumb info (even if you have a complex control).

Generally, when you are creating a control is because:

• You need to render a lot of elements with little model info, it makes your main view to be bloated, and you cannot find the model's info you are using for that main view.
• You want to reuse some elements that happen to be together more than once. Perhaps is a title where is user's name in a place and category name in another place.

Thereby, your control must be agnostic about when model's property changes. What you are looking for is the DependencyProperty.

Conversely, the INotifyPropertyChanged must be used in the ViewModel part of MVVM because it's the one who knows when:

• Business info (i. e. user's name) is changed in the Model.
• Dumb info (i.e. text) is changed in the View.

Answer 3

What are the pros and cons of each approach? How should I proceid?

1 - Make my Control implement INotifyPropertyChanged

INotifyPropertyChanged is not a specific part of WPF. Therefore, if you want a simple publish/subscribe feature this interface is a good and standard way that .NET framework provides to do it.

2 - Make Bar a readonly DependencyProperty

In my understanding, you only want the Bar property to be "published" for the client (in your case the Control template) to update itself. Therefore, you don't need a DependencyProperty in this case, because you don't want to bind it to something else like a style, template or another runtime variable.

In this case, it would work, but it seems like a workaround (because you're implementing in the control) to accomplish your feature.

3 - Another option

I'm not sure if this is applicable because your example is too general, but I suggest a third option:

• Make your control as dumb as possible;
• Make Foo and Bar DependencyProperties;
• Create a ViewModel as a DataContext to your control
• Provide the values for Foo and Bar by making your ViewModel implement INotifyPropertyChanged interface