來說明如何處理後臺執行緒通過非同步方式來更新UI。他的方案非常棒，但是客戶端稍稍複雜了一點，在非常複雜的場景可能會發生問題。我在實際工作中遇到這個問題的時候不是以非同步委託的面目出現的，而是以介面方式實現的，這樣的情況更具有一般性。我通常是在若干個訂閱端(Subscriber)實現這個“訂閱主題”的介面，在一個釋出端(Publisher)實現同樣一個介面，並提供對訂閱者的管理。事實上，在業務層實現這個釋出端的介面是容易的，但在GUI的訂閱端有可能會發生另外一些問題，例如如果業務端與GUI客戶端並不在同一個執行緒中。典型的例子就是通常將“長任務”放到某個後臺執行緒中去執行，在執行過程中可以在任何時候將執行狀態報告給前臺執行緒。顯然，這是一個處理一般性

實現的方法有點變態，和Mixin的原理很相似。在一個AsyncObjectBase的基類或者該基類的派生類上動態實現客戶端介面，同時實現對訂閱者的管理。之所以動態化是為了適應客戶端介面中的任何簽名的方法。

以下是關於AsyncObjectBase的簡單的API：

提供了兩個方法來管理訂閱者：

Register(object)：新增訂閱者。

Unregister(object)：刪除訂閱者。

提供了三個方法來管理髮布狀態：

Disable()：關閉釋出。

Enable(object)：僅開放指定的訂閱者。

Enable()：開放所有的訂閱者。

提供了兩個靜態方法來例項化介面的服務端實現：

AsyncObjectBase GetObject(Type, Type)：獲取指定基類、指定介面型別的服務端實現(指定基類必須繼承自AsyncObjectBase)。

AsyncObjectBase GetObject(Type)：獲取指定介面型別的服務端實現。

從AsyncObjectBase派生一個自定義型別來重寫委託指派方法可實現複雜的委託(不僅限於基於System.Windows.Form.Control的實現類)。這三個方法是：

void CheckDelegate(Delegate, object[], out bool)

object ChecjDelegate2(Delegate, object[], out bool)；

以上兩個方法都是捕獲委託的，差異是前者實現的委託無返回值，而後者實現的委託有返回值。最後一個引數通知伺服器該委託是否已經被捕獲，以決定是否需要繼續raise這個委託。這是本方案加入自定義委託捕獲的唯一途徑。

bool GetEnabled(object)：返回是否需要向指定委託者釋出。

示例實現這樣一個場景：後臺執行緒開啟一個文字檔案，然後一段一段地向多個訂閱者釋出。

有兩點需要說明：

一、示例未實現多介面，當然如果需要的話，改造過程非常簡單。

二、未處理帶返回值的方法的介面，當然如果需要的話，改造過程也非常簡單。

示例下載