隨著時(shí)代的發(fā)展，異步調(diào)用在編程中是不可缺少的，這里就關(guān)于WCF異步調(diào)用簡(jiǎn)單的和大家分享一下吧。WCF 與Web Service不同的是，當(dāng)我們定義了服務(wù)契約的操作時(shí)，不管是通過(guò)ChannelFactory創(chuàng)建服務(wù)代理對(duì)象，還是通過(guò)SvcUtil的默認(rèn)方式生成服務(wù)代理對(duì)象，客戶端在調(diào)用這些代理對(duì)象時(shí)，都無(wú)法直接實(shí)現(xiàn)異步方式的調(diào)用。例如，對(duì)于如下的服務(wù)操作定義：

 
[OperationContract]  
 
Stream TransferDocument(Document document);  

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

#T#這樣的設(shè)計(jì)使得我們無(wú)法通過(guò)編程方式異步地調(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ù)操作究竟是否采用異步方式，應(yīng)該由客戶端的調(diào)用者決定。因此，所有與WCF異步調(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í)行WCF異步調(diào)用呢？如果采用編程方式獲得服務(wù)代理對(duì)象，這一問(wèn)題會(huì)變得比較糟糕。因?yàn)槲覍⒎?wù)契約的定義單獨(dú)形成了一個(gè)程序集，并在客戶端直接引用了它。然而，在這樣的服務(wù)契約程序集中，是沒有包含異步方法的定義的。因此，我需要修改在客戶端的服務(wù)定義，增加操作的異步方法。這無(wú)疑為服務(wù)契約的重用帶來(lái)障礙。至少，我們需要在客戶端維持一份具有異步方法的服務(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。