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

时间:2022-06-29 03:39:57

Is it appropriate to fire a "property changed" event when the actual value of a property does not change?

当财产的实际价值没有变化时触发“财产已更改”事件是否合适?

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

This will trigger the event even when the new value is identical to the old value. Is this bad practice?

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

3 个解决方案

#1


Best practice is not to throw the event unless the value changed.

除非值发生变化,否则最佳做法不是抛出事件。

In your case the property is just an 'int', so it's just a simple equality check. If your property was an object in it's own right, there are more cases to consider

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

  1. You set the same instance again - No property change

    您再次设置相同的实例 - 没有属性更改

  2. You set a different instance with different values - Throw a property change

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

  3. You set a different, but 'equal' instance ( i.e., the two different objects have the same set of values and can be considered equivalent from your application's point of view ) - Throw a property change.

    您设置了一个不同的,但“相等”的实例(即,两个不同的对象具有相同的值集,从您的应用程序的角度来看可以认为是相同的) - 抛出属性更改。

The last one is subject to some debate... has the property really changed when all of it's attributes are the same? If someone is using that property change to subscribe to changes in the subclass, they will need it to know to unsubscribe from the old class and subscribe to the new one. Therefore I err on the side of announcing the change.

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

#2


No, don't fire the event unless the underlying value has actually changed.

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

Usually, you code the Setter such that it doesn't even bother trying to modify the underlying value unless it actually is different.

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

#3


If you had an event called PropertySetterAccessed, then it would be appropriate to fire it when the value doesn't change. However, your event is called PropertyChanged, so it should only be fired when that actually happened. If your events/methods/classes etc don't do "what they say on the tin", you are creating a maintenance nightmare for someone.

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

#1


Best practice is not to throw the event unless the value changed.

除非值发生变化,否则最佳做法不是抛出事件。

In your case the property is just an 'int', so it's just a simple equality check. If your property was an object in it's own right, there are more cases to consider

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

  1. You set the same instance again - No property change

    您再次设置相同的实例 - 没有属性更改

  2. You set a different instance with different values - Throw a property change

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

  3. You set a different, but 'equal' instance ( i.e., the two different objects have the same set of values and can be considered equivalent from your application's point of view ) - Throw a property change.

    您设置了一个不同的,但“相等”的实例(即,两个不同的对象具有相同的值集,从您的应用程序的角度来看可以认为是相同的) - 抛出属性更改。

The last one is subject to some debate... has the property really changed when all of it's attributes are the same? If someone is using that property change to subscribe to changes in the subclass, they will need it to know to unsubscribe from the old class and subscribe to the new one. Therefore I err on the side of announcing the change.

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

#2


No, don't fire the event unless the underlying value has actually changed.

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

Usually, you code the Setter such that it doesn't even bother trying to modify the underlying value unless it actually is different.

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

#3


If you had an event called PropertySetterAccessed, then it would be appropriate to fire it when the value doesn't change. However, your event is called PropertyChanged, so it should only be fired when that actually happened. If your events/methods/classes etc don't do "what they say on the tin", you are creating a maintenance nightmare for someone.

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