我从未使用过INotifyPropertyChanged，我正在考虑在新的应用程序中广泛使用它。
我的问题是，使用INotifyPropertyChanged接口以便为数据绑定控件以外的其他内容提供事件通知是否“正确”？
从网上的一些例子看来，这个界面被广泛用于通知网格等数据被更改时。我有各种各样的场景，我需要其他类通知其他类中的数据更改，我想知道你是否认为实现这个接口更简洁，并在setter上执行更改的调用，或者只是创建常规事件。
答案 0 :(得分：4)
在做出这样的选择时，我倾向于使用语言功能而不是其他结构。
INotifyPropertyChanged的一个严重缺点是它只在更新时提供属性名称作为字符串，并且您的消费类必须解析该字符串并决定如何对其执行操作。
通过事件，您可以提供事件所需的任何类型的委托签名，并且消费类可以直接对该更改起作用。
如果你偷看，你会发现INotifyPropertyChanged无论如何都是一个事件，为什么不直接使用事件呢？
答案 1 :(得分：2)
我认为你可以在这些场景中使用这个界面，但是如果你想在你的课程之间进行这样的操作，你必须要认真思考。 如果这对你有意义 - 当然，为什么重新发明轮子？
答案 2 :(得分：1)
我认为你应该继续实现INotifyPropertyChanged接口的实现，因为它就是为了这个目的，它是UI用来拾取更改的东西，没有必要自己创建自定义事件。
答案 3 :(得分：0)
WPF和Silverlight都在数据绑定系统中广泛使用INotifyPropertyChanged。如果要对对象进行数据绑定，则应定义使用INotifyPropertyChanged。 |
否则，据我所知，它不会影响.NET Framework技术。
INotifyPropertyChanged并不是通知属性何时更改的最干净方式，具体取决于您查看它的方式，因为有一个事件和一个带有属性名的字符串，您必须创建一个switch语句。相比于每个属性的事件，确实更容易实现
答案 4 :(得分：0)
我不会将INotifyPropertyChanged用于除数据绑定之外的任何内容。此界面可能是数据绑定的唯一选项，因为将对PropertyChanged事件执行操作的控件事先不知道发件人的类型。因为数据绑定必须使用这样的通用接口。
对于我自己的类型和场景，我会使用常规事件（每个属性可以更改其值的一个事件）。在这种情况下，INotifyPropertyChanged是一种字符串类型的代码。你可以看到，甚至WPF本身仍然充满了oldscool事件（FrameworkElement，例如有很多***Changed事件）。
答案 5 :(得分：0)
我认为INotifyPropertyChanged通常是有关属性值更新的基于推送的通知的正确机制。
<强>替代：
但是，它并不是实现这一目标的唯一可能机制。例如，Windows窗体还支持每个属性单独的…Changed个事件;即如果你有一个名为Foo的属性，你可以在FooChanged的setter中触发一个关联的Foo事件。
具有单独的…Changed事件具有特定于一个特定属性的优点，因此不需要观察者/订阅者过滤掉他们不感兴趣的属性的通知。另一方面，您的一旦你必须宣布50个额外的…Changed事件，（数据）对象可能会开始变得“笨重”。
有关实施INotifyPropertyChanged的一些注意事项：
如果您厌倦了一遍又一遍地重写相同的样板代码......：
public T SomeProperty
{
get { … }
set
{
if (someProperty != value)
{
someProperty = value;
NotifyPropertyChanged("SomeProperty");
}
}
}
private T someProperty;
那么你可能想要考虑一个AOP框架（比如PostSharp）。我记得在CodePlex或Google Code上有一个库，可以为你自动实现INotifyPropertyChanged（或者重写CIL字节码）;不幸的是我不记得图书馆的名字了。
还有其他相关接口INotifyPropertyChanging，INotifyListChanged等。您也可以查看这些接口。
答案 6 :(得分：0)
不要在其他场景中使用，如果你需要通知其他域类使用域事件，那将更加面向业务，描述性和强类型
答案 7 :(得分：0)
我不是UI领域之外的INPC粉丝，因为它隐藏了对象实例正在生成重要事件的事实。此外，如果我使用你的类实现INPC，我会期望所有属性广播通知，如果只有其中一些，那么这是一个在运行时可能会被忽视的错误。