WPF 过多的 PropertyChanged 事件

Question

通常，在对象的属性设置器中，我们可能希望引发 PropertyChanged 事件，例如，

    public event PropertyChangedEventHandler PropertyChanged; 
    protected void Notify(string property)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(property));
        }
    }

    public string UserNote
    {
        get { return _userNote; }
        set
        {
            _userNote = value;
            Notify("UserNote"); 
        }
    }

在我们现有的代码库中，我看到 PropertyChangedEventArgs 被发送 null 的实例，以指示对象的所有属性都已更改。这似乎效率低下，并且似乎会导致触发比需要的事件多得多的事件。它似乎还会导致对象以循环方式相互更新的问题。

这是一个好的做法吗？

代码中的注释试图证明它的合理性......

//The purpose of this method is to wire up clients of NotificationBase that are also
//NotificationBases to *their* clients. Consider the following classes:     
         public class ClassA : NotificationBase
         {
             public int Foo
             {
                 get { return 123; }
                 set { Notify("Foo"); }
             }
         }

         public class ClassB : NotificationBase
         {
             ClassA A = new ClassA();
             public ClassB()
             {
                 A.PropertyChanged += AllChanged;
             }
             public void SetFoo()
             {
                 A.Foo = 456;
             }
         }

         public class ClassC
         {
             ClassB B = new ClassB();
             public ClassC()
             {
                 B.PropertyChanged += delegate { dosomething(); };
                 B.SetFoo(); // causes "dosomething" above to be called
             }
         }

        /// ClassB.SetFoo calls ClassA.Foo's setter, which calls ClassA.Notify("Foo").
        /// The event registration in ClassB's ctor causes ClassB.AllChanged to be called, which calls
        /// ClassB.Notify(null) - implying that ALL of ClassB's properties have changed.
        /// The event registration in ClassC's ctor causes the "dosomething" delegate to be called.
        /// So a Notify in ClassA is routed to ClassC via ClassB's PropertyChanged event.

        protected void AllChanged(Object sender, PropertyChangedEventArgs e)
        {
            Notify(null);
        }

任何想法都非常感谢。

问候， 菲兹

Answer 1

这实际上是 PropertyChangedEventArgs 的设计（或其文档）存在问题。将 PropertyName 设置为 null 意味着“该对象上的所有属性都已更改”。但是，除非类是密封的，或者您使用反射，否则您实际上无法知道对象上的所有属性都已更改。您最多可以说的是对象基类中的所有属性都已更改。

在我的书中，这足以成为不使用这种特定约定的理由，除非在极少数情况下我创建了实现属性更改通知的密封类。

作为一个实际问题，你真正想做的只是引发一个事件，告诉听众“这个对象上的一大堆属性已经改变，但我不会费心去一一告诉你。 ”当你说：

我看到 PropertyChangedEventArgs 被发送为 null 的实例，以指示对象的所有属性都已更改。这看起来效率低下，并且似乎会导致触发比需要的事件多得多的事件。

……实际意图恰恰相反。如果方法更改对象的 Foo、Bar、Baz 和 Bat 属性，并且该对象具有只有四、五处房产，筹集一项活动可能比筹集四项更好。另一方面，如果对象有 60 个属性，那么引发四个事件可能会更好，使对象的每个侦听器（即使是那些不查看这四个属性的侦听器）在他们关心的属性发生更改时执行他们所做的任何操作，因为这些属性没有。

问题在于，按照设计，属性更改通知系统并不是适合每项作业的足够细粒度的工具。它被设计为完全通用的，并且不了解内置的特定应用程序域。

在我看来，这正是您的设计中所缺少的：应用程序领域知识。

在第二个示例中，如果 Fixture 对象具有（例如）十个依赖于 FixtureStatus 值的属性，则引发十个属性更改事件可能看起来有点过多。也许是的。也许该对象应该引发一个 FixtureStatusChanged 事件。然后，了解您的应用程序域的类可以侦听这一事件并忽略 PropertyChanged 事件。 （您仍然会在其他属性上引发 PropertyChanged 事件，以便不知道 FixtureStatusChanged 事件含义的对象可以保持当前状态 -也就是说，在实现 FixtureStatusChanged 后，您的类是否仍然需要实现 INotifyPropertyChanged。）

第二个注释：C# 世界中的大多数类，如果它们实现引发 Foo 事件的方法，调用该方法 OnFoo。这是一个重要的约定：它使方法和事件之间的关系变得明确，并且使调用该方法的代码引发事件的事实易于识别。 Notify 是一般方法的弱名称 - 通知谁？什么？ - 在这种情况下，它实际上混淆了一些应该明确的内容。属性更改通知非常棘手，如果您的命名约定不掩盖它正在发生的事实。

Answer 2

忽略其他内容，我认为单独使用 Notify(null) 是一种不好的做法。本质上并不清楚这意味着什么，对于工作了 5 年代码的开发人员来说，他们可能会认为这意味着其他东西，除非他们碰巧看到了这些注释。

Answer 3

我遇到过这样的情况：当我通过设置器设置其他一些属性时，计算属性（没有设置器）需要触发 PropertyChangeNotification。

例如

双数
{
获取{返回num;}
放
{
数字=值；
OnPropertyChanged("数字");
OnPropertyChanged("TwiceNumber");
}
}

double 两次数
{
得到{返回_num * 2.0;}
，

通常 我只使用仅获取属性来执行此操作，并且我不明白为什么在这种情况下，一个属性在另一个属性上触发更改通知是不好的。但我认为，如果我在其他情况下这样做，我很可能不知道自己在做什么！