WCF已經(jīng)推出就受到了廣大開發(fā)人員的關(guān)注。作為一個(gè).NET Framework 3.5的重要組成部分，它的應(yīng)用可以幫助我們創(chuàng)建一個(gè)安全性高的可依賴性框架，為開發(fā)人員帶來極大的方便。首先，為我們就先來了解一下WCF異步調(diào)用的相關(guān)介紹。

WCF與Web Service不同的是，當(dāng)我們定義了服務(wù)契約的操作時(shí)，不管是通過ChannelFactory創(chuàng)建服務(wù)代理對(duì)象，還是通過SvcUtil的默認(rèn)方式生成服務(wù)代理對(duì)象，客戶端在調(diào)用這些代理對(duì)象時(shí)，都無法直接實(shí)現(xiàn)WCF異步調(diào)用方式的調(diào)用。例如，對(duì)于如下的服務(wù)操作定義：

[OperationContract]  
Stream TransferDocument(Document document); 

在調(diào)用代理對(duì)象的方法時(shí)，我們無法找到對(duì)應(yīng)于TransferDocument()操作的BeginTransferDocument()和EndTransferDocument()異步方法。#t#

這樣的設(shè)計(jì)使得我們無法通過編程方式異步地調(diào)用服務(wù)的操作，除非我們?cè)诙x服務(wù)接口時(shí)，直接加入相關(guān)操作的異步方法。然而，這又直接導(dǎo)致了服務(wù)的設(shè)計(jì)與方法調(diào)用方式之間的耦合。一個(gè)好的框架設(shè)計(jì)要素在于，不管客戶端的調(diào)用方式（同步或者異步），服務(wù)的設(shè)計(jì)與實(shí)現(xiàn)應(yīng)該是一致的。對(duì)于服務(wù)的設(shè)計(jì)者而言，在設(shè)計(jì)之初，就不應(yīng)該去考慮服務(wù)的調(diào)用者調(diào)用的方式。換言之，服務(wù)操作究竟是否采用WCF異步調(diào)用方式，應(yīng)該由客戶端的調(diào)用者決定。因此，所有與異步調(diào)用相關(guān)的內(nèi)容應(yīng)該只與客戶端相關(guān)。WCF遵循了這一規(guī)則。

在我編寫的應(yīng)用程序中，會(huì)暴露一個(gè)傳送文檔文件的服務(wù)操作。我并不知道也并不關(guān)心調(diào)用該操作的客戶端是否采用異步方式。因此，如上所述的服務(wù)操作定義是完全正確的。

那么，客戶端究竟應(yīng)該如何執(zhí)行異步調(diào)用呢？如果采用編程方式獲得服務(wù)代理對(duì)象，這一問題會(huì)變得比較糟糕。因?yàn)槲覍⒎?wù)契約的定義單獨(dú)形成了一個(gè)程序集，并在客戶端直接引用了它。然而，在這樣的服務(wù)契約程序集中，是沒有包含異步方法的定義的。因此，我需要修改在客戶端的服務(wù)定義，增加操作的異步方法。這無疑為服務(wù)契約的重用帶來障礙。至少，我們需要在客戶端維持一份具有異步方法的服務(wù)契約。

所幸，在客戶端決定采用異步方式調(diào)用我所設(shè)計(jì)的服務(wù)操作時(shí)，雖然需要修改客戶端的服務(wù)契約接口，但并不會(huì)影響服務(wù)端的契約定義。因此，服務(wù)端的契約定義可以保持不變，而在客戶端則修改接口定義如下：

[ServiceContract]  
public interface IDocumentsExplorerService  
{  
[OperationContract]  
Stream TransferDocument(Document document);  
[OperationContract(AsyncPattern = true)]  
IAsyncResult BeginTransferDocument(Document document,  
AsyncCallback callback, object asyncState);  
Stream EndTransferDocument(IAsyncResult result);  
} 

注意，在BeginTransferDocument()方法上，必須在OperationContractAttribute中將AsyncPattern屬性值設(shè)置為true，因?yàn)樗哪J(rèn)值為false。

調(diào)用方式如下：

BasicHttpBinding binding = new BasicHttpBinding();  
binding.SendTimeout = TimeSpan.FromMinutes(10);  
binding.TransferMode = TransferMode.Streamed;  
binding.MaxReceivedMessageSize = 9223372036854775807;  
EndpointAddress address = new EndpointAddress  
("http://localhost:8008/DocumentExplorerService");  
ChannelFactory<IDocumentsExplorerService> factory =   
new ChannelFactory<IDocumentsExplorerService>(binding,address);  
m_service = factory.CreateChannel();  
……  
IAsyncResult result = m_service.BeginTransferDocument(doc,null,null);  
result.AsyncWaitHandle.WaitOne();  
Stream stream = m_service.EndTransferDocument(result); 

如果采用SvcUtil生成客戶端代理文件，可以有更好的方式實(shí)現(xiàn)WCF異步調(diào)用，也就是使用SvcUtil的/async開關(guān)，例如：

svcutil /async http://localhost:8008/DocumentExplorerService 

唯一不足的是，它會(huì)不分青紅皂白，為所有服務(wù)操作都生成對(duì)應(yīng)的異步方法。這樣的做法未免過于武斷。

合理地利用服務(wù)的WCF異步調(diào)用，可以有效地提高系統(tǒng)性能，合理分配任務(wù)的執(zhí)行。特別對(duì)于UI應(yīng)用程序而言，可以提高UI的響應(yīng)速度，改善用戶體驗(yàn)。在我編寫的應(yīng)用程序中，下載的文件如果很大，就有必要采用異步方式。

對(duì)于異步調(diào)用的完成，雖然WCF提供了諸如阻塞、等待和輪詢等機(jī)制，但***的方式還是使用回調(diào)。也就是利用Begin方法參數(shù)中的AsyncCallback對(duì)象。這是一個(gè)委托對(duì)象，它的定義如下所示：

public delegate void AsyncCallback(IAsyncResult ar); 

利用WCF異步調(diào)用方式執(zhí)行服務(wù)操作，使得服務(wù)在執(zhí)行過程中不會(huì)阻塞主線程，當(dāng)方法執(zhí)行完成后，通過AsyncCallback回調(diào)對(duì)應(yīng)的方法，可以通知客戶端服務(wù)執(zhí)行完畢。例如：

//Invoke it Asynchronously  
m_service.BeginTransferDocument(m_doc,OnTransferCompleted,null);  
//Do some work;  
//callback method  
void OnTransferCompleted(IAsyncResult result)  
{  
Stream stream = m_service.EndTransferDocument(result);  
result.AsyncWaitHandle.Close();  
lbMessage.Text = string.Format("The file {0} 
had been transfered sucessfully.",   
m_doc.FileName);  
} 

在調(diào)用BeginTransferDocument()方法之后，主線程不會(huì)被阻塞，仍然可以繼續(xù)執(zhí)行其它工作。而當(dāng)服務(wù)方法執(zhí)行完畢之后，會(huì)自動(dòng)調(diào)用回調(diào)方法，執(zhí)行方法中的內(nèi)容。