建站
咨詢
售后
建站咨詢
新聞中心
異步調用是編程中不可缺少的，在工作中積累一點經(jīng)驗，現(xiàn)在我們里關注一下WCF異步調用。WCF 與Web Service不同的是，當我們定義了服務契約的操作時，不管是通過ChannelFactory創(chuàng)建服務代理對象，還是通過SvcUtil的默認方式生成服務代理對象，客戶端在調用這些代理對象時，都無法直接實現(xiàn)異步方式的調用。例如，對于如下的服務操作定義：
專注于為中小企業(yè)提供成都網(wǎng)站建設、網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)華坪免費做網(wǎng)站提供優(yōu)質的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000+企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉變。
- [OperationContract]
- Stream TransferDocument(Document document);
在調用代理對象的方法時，我們無法找到對應于TransferDocument()操作的BeginTransferDocument()和EndTransferDocument()異步方法。
#T#這樣的設計使得我們無法通過編程方式異步地調用服務的操作，除非我們在定義服務接口時，直接加入相關操作的異步方法。然而，這又直接導致了服務的設計與方法調用方式之間的耦合。一個好的框架設計要素在于，不管客戶端的調用方式（同步或者異步），服務的設計與實現(xiàn)應該是一致的。對于服務的設計者而言，在設計之初，就不應該去考慮服務的調用者調用的方式。換言之，服務操作究竟是否采用異步方式，應該由客戶端的調用者決定。因此，所有與WCF異步調用相關的內容應該只與客戶端相關。WCF遵循了這一規(guī)則。
在我編寫的應用程序中，會暴露一個傳送文檔文件的服務操作。我并不知道也并不關心調用該操作的客戶端是否采用異步方式。因此，如上所述的服務操作定義是完全正確的。
那么，客戶端究竟應該如何執(zhí)行WCF異步調用呢？如果采用編程方式獲得服務代理對象，這一問題會變得比較糟糕。因為我將服務契約的定義單獨形成了一個程序集，并在客戶端直接引用了它。然而，在這樣的服務契約程序集中，是沒有包含異步方法的定義的。因此，我需要修改在客戶端的服務定義，增加操作的異步方法。這無疑為服務契約的重用帶來障礙。至少，我們需要在客戶端維持一份具有異步方法的服務契約。
所幸，在客戶端決定采用異步方式調用我所設計的服務操作時，雖然需要修改客戶端的服務契約接口，但并不會影響服務端的契約定義。因此，服務端的契約定義可以保持不變，而在客戶端則修改接口定義如下：
- [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屬性值設置為true，因為它的默認值為false。
網(wǎng)站名稱：全面概括WCF異步調用方法
文章URL：http://m.5511xx.com/article/coshcjp.html
