我們從Web應用程序中獲取了一個WCF服務。我們使用的客戶端是使用Visual Studio的「Add Service Reference」選項生成的。由於它是一個網絡應用程序,並且由於應用程序的性質很可能會導致相對較短的會話,因此我們選擇在用戶登錄並在會話的整個生命週期內保留該客戶端時創建客戶端實例,然後在會話結束時處理它。處理持久WCF客戶端進入故障狀態
這使我想到了我的問題 - 我們試圖確定處理客戶端通道進入故障狀態的最佳方式。周圍的一些搜索後,我們來到了這一點:
if(client.State = CommuncationState.Faulted)
{
client = new Client();
}
try
{
client.SomeMethod();
}
catch //specific exceptions left out for brevity
{
//logging or whatever we decide to do
throw;
}
然而,這並不工作,由於這樣的事實,至少在我們的情況下,即使服務已關閉,客戶端會顯示Open
狀態,直到您實際嘗試使用它進行呼叫,然後進入Faulted
狀態。
所以這讓我們去做別的事情。我們想出的另一個選項是:
try
{
client.SomeMethod();
}
catch
{
if(client.State == CommunicationState.Faulted)
{
//we know we're faulted, try it again
client = new Client();
try
{
client.SomeMethod();
}
catch
{
throw;
}
}
//handle other exceptions
}
但是那種氣味。顯然,我們可以通過使用新客戶端並在每次調用時處理它來避免這種情況。這似乎是不必要的,但如果這是正確的方式,那麼我想這就是我們會選擇的。那麼,優雅地處理確定客戶是否處於故障狀態,然後對其進行處理的最佳方式是什麼?我們是否應該爲每次通話都獲得新客戶?
要記住的另一件事 - 客戶端的實例化以及所有這些檢查和處理髮生在客戶端的包裝類中。如果我們按照我們的意圖這樣做,它對應用程序本身就是透明的 - 調用它們並處理它們的異常不需要特殊的代碼。
什麼導致客戶端進入故障狀態?我一直可以讓WCF服務正常返回錯誤,客戶可以繼續關注它的業務。服務器沒有響應或什麼? – Tridus 2011-03-28 23:16:45
在這種情況下,我們使用ASP.NET成員資格,並且通過超出「userIsOnlineTimeWindow」屬性來運行它。很明顯,在這種情況下,將用戶重定向到登錄頁面是有意義的,但我們正在努力確保我們已準備好應對可能陷入故障狀態的其他任何情況。 – Zannjaminderson 2011-03-29 13:30:04