WCF中的非同步回撥

WCF與Web Service不同的是，當我們定義了服務契約的操作時，不管是通過ChannelFactory建立服務代理物件，還是通過SvcUtil的預設方式生成服務代理物件，客戶端在呼叫這些代理物件時，都無法直接實現非同步方式的呼叫。例如，對於如下的服務操作定義：
在呼叫代理物件的方法時，我們無法找到對應於TransferDocument()操作的BeginTransferDocument()和EndTransferDocument()非同步方法。

這樣的設計使得我們無法通過程式設計方式非同步地呼叫服務的操作，除非我們在定義服務介面時，直接加入相關操作的非同步方法。然而，這又直接導致了服務的設計與方法呼叫方式之間的耦合。一個好的框架設計要素在於，不管客戶端的呼叫方式（同步或者非同步），服務的設計與實現應該是一致的。對於服務的設計者而言，在設計之初，就不應該去考慮服務的呼叫者呼叫的方式。換言之，服務操作究竟是否採用非同步方式，應該由客戶端的呼叫者決定。因此，所有與非同步呼叫相關的內容應該只與客戶端相關。WCF遵循了這一規則。

在我編寫的應用程式中，會暴露一個傳送文件檔案的服務操作。我並不知道也並不關心呼叫該操作的客戶端是否採用非同步方式。因此，如上所述的服務操作定義是完全正確的。

那麼，客戶端究竟應該如何執行非同步呼叫呢？如果採用程式設計方式獲得服務代理物件，這一問題會變得比較糟糕。因為我將服務契約的定義單獨形成了一個程式集，並在客戶端直接引用了它。然而，在這樣的服務契約程式集中，是沒有包含非同步方法的定義的。因此，我需要修改在客戶端的服務定義，增加操作的非同步方法。這無疑為服務契約的重用帶來障礙。至少，我們需要在客戶端維持一份具有非同步方法的服務契約。

所幸，在客戶端決定採用非同步方式呼叫我所設計的服務操作時，雖然需要修改客戶端的服務契約介面，但並不會影響服務端的契約定義。因此，服務端的契約定義可以保持不變，而在客戶端則修改介面定義如下：

注意，在BeginTransferDocument()方法上，必須在OperationContractAttribute中將AsyncPattern屬性值設定為true，因為它的預設值為false。

呼叫方式如下：

如果採用SvcUtil生成客戶端代理檔案，可以有更好的方式實現非同步，也就是使用SvcUtil的/async開關，例如：

唯一不足的是，它會不分青紅皁白，為所有服務操作都生成對應的非同步方法。這樣的做法未免過於武斷。

合理地利用服務的非同步呼叫，可以有效地提高系統效能，合理分配任務的執行。特別對於UI應用程式而言，可以提高UI的響應速度，改善使用者體驗。在我編寫的應用程式中，下載的檔案如果很大，就有必要採用非同步方式。

對於非同步呼叫的完成，雖然WCF提供了諸如阻塞、等待和輪詢等機制，但最好的方式還是使用回撥。也就是利用Begin方法引數中的AsyncCallback物件。這是一個委託物件，它的定義如下所示：

利用非同步方式執行服務操作，使得服務在執行過程中不會阻塞主執行緒，當方法執行完成後，通過AsyncCallback回撥對應的方法，可以通知客戶端服務執行完畢。例如：

在呼叫BeginTransferDocument()方法之後，主執行緒不會被阻塞，仍然可以繼續執行其它工作。而當服務方法執行完畢之後，會自動呼叫回撥方法，執行方法中的內容。

上述實現存在一個問題，就是對於lbMessage控制元件的操作。由於回撥方法並非執行在主執行緒中，如果回撥方法需要更新與非同步呼叫結果相關的介面，例如本例中的lbMessage控制元件，則需要將回撥的呼叫封送(Marshal)到當前主程式介面的同步上下文中。我們可以使用SynchronizationContext以及它的SendOrPostCallback委託，對呼叫進行封送：

則回撥方法修改為：

在呼叫非同步方法時，由於對BeginTransferDocument()和EndTransferDocument()方法的呼叫可能會在不同的方法體中，因而我將服務代理物件定義為private欄位。如果希望將服務物件定義為一個區域性變數，可以在呼叫BeginTransferDocument()方法時，將代理物件傳遞到方法的asyncState引數中，然後在呼叫EndTransferDocument()方法之前，通過IAsyncResult獲得準確的服務代理物件：

將m_service作為asyncState物件傳入之後，在呼叫EndTransferDocument()方法之前，就可以根據它先獲得服務代理物件：