異步Web服務設計模式

當編寫一個Silverlight應用程序連接到WCF Web服務時，我們在使用Web服務時唯一提供的選項是對WS接口進行異步調用。異步Web服務設計模式

即

WebService client = new WebService(); 
client.ServiceMethodCompleted += new EventHandler<Args>(client_Handler); 
client.ServiceMethodAsync(); 
client.close() 

...followed by 
void client_Handler(object sender, Args e) 
{ 
    //Next step, possibly another method? 
}

雖然我寫的webapps當（安全網）瞭解異步調用的原因，將一個其中每個步驟是依賴的結果，使用什麼類型的設計模式，如果一個方法是寫Web服務調用？例如，如果在Web服務中有一種方法檢查訪問者的用戶憑證，並且取決於該用戶的組，則會執行某些操作。

public MyPage() //Constructor 
{ 
    CheckCredentialsAsync(); 

    if(result.IsUserTypeA) 
    { 
     //something complex 
    } 
    else if(result.IsUserTypeB) 
    { 
     //something else complex 
    } 
    ...etc 

}

有沒有辦法做到這一點，而不使用由先前的異步調用完成的事件引發了「多米諾骨牌」的方法設計？看起來如果有很多客戶/服務交互可能會變得混亂。

謝謝！

來源

2009-10-26 Erik Kerber

我知道這種模式的最佳建模是事件驅動的有限狀態機。異步方法完成是事件，您的「複雜操作」是操作，MyPage實例是當前狀態。然而，對於任何相當數量的狀態和事件，FSM可能會相當多毛，雖然他們可以通過組合更簡單的FSM進行檢查，但我不會將這種模式直觀而簡單地稱爲任何延伸。

坦率地說，我經常更喜歡你描述的回調鏈。「多米諾骨牌效應」並不是非常糟糕，一旦你寫了一些這樣的模塊，你就會掌握它。它的複雜性基本上是由'複雜的'塊中可能的執行分支的數量所驅動的。在同步路徑中，如果您有一個if分支，那麼在異步路徑中，您可能會有兩個單獨的回調。更多的代碼需要輸入，但並不是很難理解。而'更多的代碼'部分可以照顧正確的coe工廠成爲助手。

我認爲雖然我沒有使用Silverlight類，但我的經驗主要圍繞WebRequest，SqlClient和Stream操作的異步行爲。最後，我發現最複雜的部分是錯誤處理和資源所有權的分割，因爲using模式對於異步來說遠沒有用處。

來源

2009-10-27 00:20:05

如果你不想鏈回調在一起，看看傑弗裏裏希特的AsyncEnumerator： http://www.wintellect.com/PowerThreading.aspx

它支持的Silverlight了。

來源

2009-10-31 07:55:30 Brannon

我同意你的觀點：
在呼叫的長骨牌鏈看是醜陋的。它混淆了代碼，因爲在您的頁面中調用回調的（無窮盡的）列表不一定與其他開發人員通信，因爲給定系列是任何單個集合的一部分。這就是爲什麼我會使用設計模式將這些調用包裝到單個對象中。

如果您的多米諾骨牌連鎖電話...

使用以前的電話的數據：
我將包裹這些調用到使用DECORATOR屈尊圖案的物體。一個使用裝飾模式的例子是STREAM對象。

如果調用您的多米諾骨牌鏈...

不使用以前的調用數據：
我將這些調用包裝到使用CHAIN OF RESPONSIBILITY屈尊圖案的物體。

無論其
有很多原因，你可能使用或不使用一個或最等。我只是想迎合你的具體情況。 Here is how you decide which one to use.

來源

2011-02-10 13:35:15

異步Web服務設計模式

回答

相關問題