INotifyPropertyChanged和plain事件为什么要相互排斥？

Question

MS推荐

INotifyPropertyChanged Interface on MSDN状态：

对于变更通知至发生在绑定的客户端 和数据源之间的绑定，绑定类型要么：

• 贯彻INotifyPropertyChanged接口（首选）。

• 为绑定类型的每个属性提供更改事件。

不要这样做。

这个问题围绕着为什么“不这样做”。

上下文

我在写一个运行服务器端的程序。一堆类意味着在本地使用，并作为对使用WCF的HTTP客户端请求（不通知客户端）的请求发送。对于这个purpore，它们是从XML模式（这样产生的预生成事件："$(TargetFrameworkSDKToolsDirectory)xsd.exe" "$(ProjectDir)generated\SystemState.xsd" /classes /enableDataBinding /namespace:XXX /o:"$(ProjectDir)generated"

的/enableDataBinding选项就派上用场了具有自动通知（所有通知接收器是服务器端）

。

这对于一些通知接收者（服务器状态更改触发一些相关代码）非常有用，对这些细节甚至不感兴趣，只是为了知道属性更改，这与INotifyPropertyChanged非常吻合。一些收款人特别关注某一特定物业的变化，这很适合“普通”MyFooChanged事件。

选择

我有两个选择：

接收通用 PropertyChanged事件

• 写接收机码，过滤器基于类型为字符串的属性名称...感觉像Code smell（无差错容易出错，缺少编译时检查等）。

• 使用通用PropertyChanged事件接收器的地方是最好的，加写一个或两个“朴素”事件MyFooChanged的一些属性，一些特定的接收器有兴趣，所有的事件接收器将保持简单，干净。

第二个看起来更清洁但违反了微软的建议。

MS建议在这里有重点吗？

在这种情况下，我真的应该担心微软说“不要这样做”吗？幽默致敬下面XKCD陈述问题的精神：

我觉得没有任何问题的权利，但它可能是有趣的讨论原因，微软州两者都做。

• 在哪种情况下两者都不好？ Windows窗体？ WPF？
• 如果你们俩都做了，会发生什么？在一些控件中重复更新？ （从.NET 1.1开始，大多数MS类都会对此进行检查。）
• 还有什么？

干杯，

Answer 1

在这方面会是不好做两者兼而有之？ Windows窗体？ WPF？

两者均支持INotifyPropertyChanged和PropertyNameChanged基于事件的通知，所以它在数据绑定时会普遍适用。

如果你俩都做了，会发生什么？在一些控件中重复更新？

这不是很容易回答这个问题（一个明确的答案不仅仅是阅读相关的来源）。显然会有很多不必要的重复工作在进行;在像这样的只读场景中，我不会期望烟花爆竹。

还有什么？

我看到的主要问题是缺乏一致性，这会导致误解，从而导致错误的代码。

如果没有特别的因素发挥作用，强烈建议做其他事情，我只会去INotifyPropertyChanged，因为它是众所周知的，立即理解并在事件处理程序上变得更轻。你也可以用use expression trees来强制输入。