Should I raise INotifyPropertyChanged when the value changes or when set has been called?

Question

When implementing INotifyPropertyChanged, should PropertyChanged only be called when n != value or should it be called because set has been called?

What I am looking for here is an industry standard recommendation (if such a thing exists) for which implementation is better and why.

Example 1 - illustrates a "dumb" event raising strategy

class Person : INotifyPropertyChanged
{
    private string name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get
        {
            return name;
        }

        set
        {
            name = value;
            PropertyChanged(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }
}

Use cases with Example 1

Person p = new Person();

p.Name = "John"; // ProperyChanged fired
p.Name = "John"; // ProperyChanged fired

Example 2 - illustrates a "clever" event raising strategy

class Person : INotifyPropertyChanged
{
    private string name;

    public event PropertyChangedEventHandler PropertyChanged;

    public string Name
    {
        get
        {
            return name;
        }

        set
        {
            if(name != value)
            {
                name = value;
                PropertyChanged(this, new PropertyChangedEventArgs(nameof(Name)));
            }
        }
    }
}

Use cases with Example 2

Person p = new Person();

p.Name = "John"; // ProperyChanged fired
p.Name = "John"; // ProperyChanged ignored as name == value

Notice if(name != value) in Example 2, which would only allow a value change, and ProperyChanged event when the incoming value does not match the existing value.

That's the great thing about coding: you can make it do whatever you want it to do. — Jeroen Vannevel, Oct 08 '16 at 10:17
I was just wondering if there was a "recommended" approach between the two, and why? — Matthew Layton, Oct 08 '16 at 10:18
You've laid out the two options and the pros of the second version. It totally depends on your usecase. It's very well possible that you want to get every event just like it's possible you might want only true changes. — Jeroen Vannevel, Oct 08 '16 at 10:21
@JeroenVannevel I get that it's kind of an "it depends" answer. I was just wondering from a performance perspective as Example 1 seems like it might become a bit expensive if the object is hit frequently. — Matthew Layton, Oct 08 '16 at 10:23
I somewhat dissagre on the closure due to `oppinion based`, OP is asking if any standard exists, and the pro's and cons that comes with them. Although it isn't as strictly defined as namespaces or varriable naming conventions (e.g.: http://stackoverflow.com/questions/918894/namespace-naming-conventions#918913) it is helpfull to know which standards are defined and what is considered to be best practice. — Stefan, Oct 12 '16 at 13:27

Stefan · Accepted Answer · 2016-10-08T10:30:46.287

As the name of the interface suggest, INotifyPropertyChanged, and according to msdn:

The INotifyPropertyChanged interface is used to notify clients, typically binding clients, that a property value has changed.

It would be best to fire the event only on a changed value.

https://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged(v=vs.110).aspx

The typical implementation patter would be something like:

public string Foo
{
    get { return _foo; }
    set
    {    
        if (string.Equals(_foo, value)) return;

        _foo= value;
        OnPropertyChanged();
    }
}

By the way, this is also the ReSharper's convention as can be found here; https://www.jetbrains.com/help/resharper/2016.1/Coding_Assistance__INotifyPropertyChanged_Support.html

As a side note: fireing only on a changed value will protect you from circulair dependencies when updating values that are computed from other values.

example: conider the following code:

public string DependentFoo
{
    get { return _foo; }
    set
    {    
        if (string.Equals(_foo, value)) return;

        _foo= value;

        //if some condition:
        DependentBar = "";
        OnPropertyChanged();
    }
}

public string DependentBar
{
    get { return _bar; }
    set
    {    
        if (string.Equals(_bar, value)) return;

        _bar = value;

        //if some condition:
        DependentFoo = "";
        OnPropertyChanged();
    }
}

Although this isn't a great example, I think you'll get the point.

score 2 · Answer 2 · answered Oct 08 '16 at 10:23

The documentation of INotifyPropertyChanged says that the purpose of the interface is

Notifies clients that a property value has changed.

This clearly refers to the "property value" changing. The examples on the documentation page also use the pattern as in your example 2.

score -2 · Answer 3 · answered Oct 08 '16 at 10:26

There is no "right" way of doing it. It all depends on what you need it to do. For example:

If all you need is to update the GUI then I'd say that Calling PropertyChanged when the property has infact not changed is unneccesary. However if you would like to use the event for other purposes (such as logging or something similar) then it could most definetly be a solution.

Should I raise INotifyPropertyChanged when the value changes or when set has been called?

3 Answers3