我们从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