事件和回調
Ken Bergmenn
MSDN開發組
什么時候使用一個事件（或連接點）接口以及什么時候使用特定的回調接口是很難理解的。他們有點類似，但在很多方面還是有很大的差異。下面將概述一些基本問題，這些基本問題在試圖決定如何繼續進行你的組件時是應該考慮到的。
我認識你嗎？
事件接口和回調接口之間關鍵的概念差異是事件被設計得更象一個匿名廣播，而回調函數則更象一個"握手"聯絡方式。雖然其他重要問題也需要闡明，但是關于使用哪一個技術關鍵決定于匿名性。
開始熟悉
任意對一個事件源有訪問的對象都能通過簡單地把那個索引放進WithEvents變量來處理源提出的事件。在C++中處理連接點與之有相當的關聯，但是前提是一樣的。在任意一種情況下，事件源對什么對象可能正在處理自己的事件沒有任何概念。可能有許多個對象正與之密切相連但也可能一個也沒有。關鍵之處是事件源盲目地通知每一個被連接的客戶機通過它的事件連接點接口，但并不知道是否客戶機正在執行處理事件。
相反地，一個設計用來執行回調的服務器必須有一個明顯的對每個需要通知的對象的訪問，它必須連接和管理這些訪問，而且最后它還必須執行通知。基本上，服務器必須清楚地知道有多少個客戶機以及如何與他們中的每一個連接和交互。
事件順序
在Microsoft Visual Basic事件接口中，一個事件源不能控制客戶機接受他們的事件的順序。這話反之也是正確的。客戶機不能肯定與別的客戶機相比用一種特定的順序接受通知。即使你要在C++中滾動你自己的連接點，后者也是正確的。
另一方面，一個回調服務器必須控制它調回客戶機的順序。當然，在一個回調服務器上做這些工作會有好處。比如，一個源服務器可能被設計用來給某些客戶機高優先級的通知，或它可能執行一些特定的基于回調結果的動作。這個靈活性在下一點中將更有意義。
誰負責
當事件服務器提出一個事件，它的所有的客戶機都得到了在事件服務器能重新得到控制之間處理事件的機會。所以，如果許多客戶機都在聽候事件，通知處理將花費難以預知的時間。另一方面，一個回調服務器，因為它對執行通知處理負責，所以在它對客戶機做的每個調用它都能重新得到控制。
因為控制級別在這里是有效的，回調可以采用比事件更靈活的技術來進行客戶通知。
現在，讓我們來考慮一下事件的參數會發生什么變化。因為事件服務器直到所有的客戶機都已經處理了特定的事件后才能重新得到控制，所有特定客戶機的ByRef參數的變化已經丟失了。只有最后一個客戶機參數發生的變化能被事件服務器看見。當考慮到哪一個客戶機被通知的順序不能得到保證的事實時，這確實變得不方便。當然，對于回調服務器，服務器對這個處理負責，所有每一個客戶機的反饋都能被獨立地分析。事實上，一個回調服務器可能希望在通知每一個客戶機時傳遞新值。
處理錯誤
兩種途徑之間最終的編譯差異在于錯誤的處理方式。如果在一個客戶機的事件處理器中發生了錯誤，則事件源不會被通知。處理事件的客戶機甚至可能非常可怕地崩潰掉，而事件源并不知道，當然，客戶機的致命錯誤也只能是使服務器崩潰（如果它是一個處理中的元件）。在這種情況中，事件服務器將不知道為什么崩潰，甚至不知道發生了錯誤。
當然，在任意執行問題中，測量你自己的需要的唯一辦法是實驗，基準和測試。你自己可以試試重排列，并作作數學演算。如果你真的想得到絕對的最后速度沖刺，那么做測試是得到保證的唯一方法，而不能相信你曾經得到什么樣的承諾。