为什么INotifyPropertyChanged和普通事件是互斥的？

Question

MS推荐

INotifyPropertyChanged Interface on MSDN州：

  

用于在绑定客户端之间的绑定中发生更改通知   和数据源，你的绑定类型应该是：

     

  

• 实施INotifyPropertyChanged界面（首选）。

  

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

  

     

不要两者兼顾。

问题围绕着为什么“不要两者兼顾”。

上下文

我正在编写一个运行服务器端的程序。一堆类意味着在本地使用，并作为使用WCF的HTTP客户端请求的回答发送（不向客户端通知）。对于这个紫癜，它们是从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强力打字。