如果

Question

是異步引發所有事件的推薦做法如果類（事件引發對象）對客戶端對象如何處理事件的參數沒有興趣，建議如何異步引發所有事件（事件的接收者）？

請引導我嗎？

Answer 1

不，這不是推薦的做法。

你必須考慮其他因素，如：

• 的generting類的線程關聯性的要求。
• 無論UI元素都參與（一個上螺紋親和力變化）
• 無論對事件作出響應可以接受多個線程的併發處理的類（又名是它們線程）。
• 是否存在涉及線程本地數據（例如Thread.CurrentPrincipal，HttpContext等）
• 無論您是從多線程處理中獲得什麼，

多線程使事情變得複雜。異步事件處理需要多線程。如果它向您購買了一些東西（例如，改進的性能，更敏感的用戶交互，簡化更復雜的其他東西），則只應該引入複雜性。

不知道具體情況的細節，不可能推薦異步事件是否合適。但所有的事情都是平等的 - 我會避免異步事件，除非我有強烈的理由。

Answer 2

不，它不是。事實上，非同尋常地舉辦活動可能會在您的計劃中引入大量新問題。除非你有令人信服的理由，否則你不應該這樣做。

Answer 3

不，不建議練習。所有通常的注意事項都適用，因爲您需要確保不會發生死鎖和比賽。

簡而言之，如果所有事件都可以異步調用，那將是非常好的，但是您必須謹慎使用任何多線程代碼庫。

Answer 4

我想添加一些除了LBushkin的偉大答案之外的東西。

這種方法的另一個問題是，你將採取一個確定的模式（事件），基本上沒有警告用戶改變函數的方式。這是混淆用戶並在其應用程序中創建錯誤的祕訣。

是的，你可以爭辯說，人們應該閱讀文檔。但是真正的誰會閱讀標準.Net事件的文檔，看看它是否像.Net框架中的其他任何事件一樣被解僱。答案不是太多人。

除非有非常有說服力的理由，否則一般來說，打破已有模式是一個壞主意。