1

女士推荐

MSDN 上的 INotifyPropertyChanged 接口状态：

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

  • 实现 INotifyPropertyChanged 接口（首选）。

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

不要两者都做。

问题围绕着为什么“不要两者都做”。

语境

我正在编写一个运行服务器端的程序。一堆类打算在本地使用，并作为使用 WCF 的 HTTP 客户端请求的答案发送（不通知客户端）。为此，它们是从 XML 模式生成的（例如在预构建事件中："$(TargetFrameworkSDKToolsDirectory)xsd.exe" "$(ProjectDir)generated\SystemState.xsd" /classes /enableDataBinding /namespace:XXX /o:"$(ProjectDir)generated" .

该/enableDataBinding选项可以方便地进行自动通知（所有通知接收器都是服务器端的）。

这对于某些通知接收器来说非常有用（服务器状态更改会触发一些相关代码）。那些甚至对细节都不感兴趣，只是想知道一个属性更改，这非常适合 INotifyPropertyChanged。

但是一些接收者对一个特定的属性变化特别感兴趣，这非常适合“普通”MyFooChanged事件。

选择

我有两个选择：

  • 编写接收通用PropertyChanged事件的接收器代码，基于字符串类型的属性名称进行过滤......感觉就像代码异味（容易出错，缺乏编译时检查等）。

  • PropertyChanged在最好的情况下为接收器使用通用事件，并MyFooChanged为某些特定接收器感兴趣的少数属性编写一两个“普通”事件。所有事件接收器都将保持简单和干净。

第二个看起来更干净，但违反了 Microsoft 的建议。

MS 的推荐在这里有意义吗？

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

XKCD 608 : 不要在这个空间写

我认为现在没有问题，但讨论微软声明不两者都做的原因可能会很有趣。

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

干杯，

4

1 回答 1

2

在哪种情况下两者都做不好？Windows 窗体？WPF ?

支持INotifyPropertyChanged和PropertyNameChanged基于事件的通知，因此当您进行数据绑定时它会普遍适用。

如果你两者都做会发生什么？某些控件中的重复更新？

回答这个问题并不容易（明确的答案不仅仅是阅读相关资料）。显然会有很多不必要的重复工作。在像这样的只读场景中，我不会完全期待烟花。

还有什么？

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

如果没有特殊因素强烈建议不这样做，我会选择这样做，INotifyPropertyChanged因为它是众所周知的，立即被理解并且在事件处理程序上更轻松。您也可以使用表达式树使其成为强类型。

于 2013-09-16T19:06:24.947 回答