什么时候应该解雇“财产变更”事件？

Question

当属性的实际值没有改变时，触发“属性已更改”事件是否合适？

public int SomeProperty
{
    get { return this.mSomeProperty; }
    set
    {
        this.mSomeProperty = value;
        OnPropertyChanged(new PropertyChangedEventArgs("SomeProperty"));
    }
}

即使新值与旧值相同，也会触发事件。这是不好的做法吗？

Answer 1

除非更改值，否则最佳做法是不抛出事件。

在你的情况下，属性只是一个'int'，所以它只是一个简单的相等检查。如果您的财产本身就是一个对象，则需要考虑更多案例

1. 您再次设置相同的实例 - 无属性更改

2. 您使用不同的值设置不同的实例 - 抛出属性更改

3. 您设置了一个不同的，但是“相等”的实例（即，两个不同的对象具有相同的值集，并且从您的应用程序的角度来看可以被认为是等效的） - 抛出属性更改。

最后一个会受到一些争论......当所有属性都相同时，属性是否真的发生了变化？如果有人使用该属性更改来订阅子类中的更改，则需要它知道取消订阅旧类并订阅新类。因此，我在宣布改变方面犯了错误。

Answer 2

不，除非基础值实际发生变化，否则不要触发事件。

通常，您对Setter进行编码，使得它甚至不会尝试修改基础值，除非它实际上是不同的。

Answer 3

如果您有一个名为PropertySetterAccessed的事件，则在值未更改时触发它是合适的。但是，您的事件称为PropertyChanged，因此只有在实际发生时才会触发它。如果你的事件/方法/课程等没有做“他们在锡上说的话”，你就会为某人制造维护噩梦。