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來強制輸入。