我喜欢在using块中实例化我的WCF服务客户端，因为它几乎是使用实现IDisposable的资源的标准方式:
using (var client = new SomeWCFServiceClient())
{
//Do something with the client
}
但是，正如这篇MSDN文章中提到的，将WCF客户端包装在using块中可能会掩盖导致客户端处于故障状态(如超时或通信问题)的任何错误。长话短说，当调用Dispose()时，客户端的Close()方法会触发，但会抛出一个错误，因为它处于故障状态。然后，原始异常被第二个异常掩盖。不好的。
在MSDN文章中建议的解决方法是完全避免使用using块，而是实例化你的客户端，并像这样使用它们:
try
{
...
client.Close();
}
catch (CommunicationException e)
{
...
client.Abort();
}
catch (TimeoutException e)
{
...
client.Abort();
}
catch (Exception e)
{
...
client.Abort();
throw;
}
与using块相比，我认为它很难看。每次需要客户端时都要写大量代码。
幸运的是，我找到了一些其他的解决方法，比如IServiceOriented博客上的这个(现在已经不存在了)。你可以这样开始:
public delegate void UseServiceDelegate<T>(T proxy);
public static class Service<T>
{
public static ChannelFactory<T> _channelFactory = new ChannelFactory<T>("");
public static void Use(UseServiceDelegate<T> codeBlock)
{
IClientChannel proxy = (IClientChannel)_channelFactory.CreateChannel();
bool success = false;
try
{
codeBlock((T)proxy);
proxy.Close();
success = true;
}
finally
{
if (!success)
{
proxy.Abort();
}
}
}
}
这就允许:
Service<IOrderService>.Use(orderService =>
{
orderService.PlaceOrder(request);
});
这还不错，但我不认为它像using块那样具有表现力和易于理解。
我目前正在尝试使用的解决方法是我第一次在blog.davidbarret.net上读到的。基本上，无论在哪里使用客户机的Dispose()方法，都要重写它。喜欢的东西:
public partial class SomeWCFServiceClient : IDisposable
{
void IDisposable.Dispose()
{
if (this.State == CommunicationState.Faulted)
{
this.Abort();
}
else
{
this.Close();
}
}
}
这似乎能够允许using块再次出现，而不会有隐藏故障状态异常的危险。
那么，使用这些变通方法还有其他需要注意的问题吗?有没有人想出更好的办法?
我的方法是创建一个显式实现IDisposable的继承类。这对于使用gui添加服务引用(添加服务引用)的人很有用。我只是在项目中删除这个类，使服务引用，并使用它而不是默认客户端:
using System;
using System.ServiceModel;
using MyApp.MyService; // The name you gave the service namespace
namespace MyApp.Helpers.Services
{
public class MyServiceClientSafe : MyServiceClient, IDisposable
{
void IDisposable.Dispose()
{
if (State == CommunicationState.Faulted)
{
Abort();
}
else if (State != CommunicationState.Closed)
{
Close();
}
// Further error checks and disposal logic as desired..
}
}
}
注意:这只是dispose的一个简单实现，如果你喜欢，你可以实现更复杂的dispose逻辑。
然后你可以用安全客户端替换常规服务客户端的所有调用，如下所示:
using (MyServiceClientSafe client = new MyServiceClientSafe())
{
var result = client.MyServiceMethod();
}
我喜欢这个解决方案，因为它不需要我访问接口定义，我可以使用using语句，因为我期望，同时允许我的代码看起来或多或少相同。
您仍然需要处理可以抛出的异常，正如在本线程的其他注释中指出的那样。
这是微软推荐的处理WCF客户端调用的方法:
有关更多详细信息，请参见:预期异常
try
{
...
double result = client.Add(value1, value2);
...
client.Close();
}
catch (TimeoutException exception)
{
Console.WriteLine("Got {0}", exception.GetType());
client.Abort();
}
catch (CommunicationException exception)
{
Console.WriteLine("Got {0}", exception.GetType());
client.Abort();
}
额外的信息
很多人似乎都在WCF上问这个问题，以至于微软甚至创建了一个专门的示例来演示如何处理异常:
WCF c: \ WF_WCF_Samples \ \基本\ Client \ ExpectedExceptions \ CS \客户机
下载示例:
c#或VB
考虑到使用语句有这么多的问题，(激烈?)关于这个问题的内部讨论和线程，我不会浪费时间试图成为一个代码牛仔，找到一个更干净的方法。我只是接受它，为我的服务器应用程序以这种冗长(但可信)的方式实现WCF客户机。
可选的附加失败
许多异常派生于CommunicationException，我认为大多数异常都不应该重新尝试。我费力地浏览了MSDN上的每个异常，并找到了一个可重试异常的简短列表(除了上面的TimeOutException)。如果我错过了应该重试的异常，请告诉我。
// The following is typically thrown on the client when a channel is terminated due to the server closing the connection.
catch (ChannelTerminatedException cte)
{
secureSecretService.Abort();
// todo: Implement delay (backoff) and retry
}
// The following is thrown when a remote endpoint could not be found or reached. The endpoint may not be found or
// reachable because the remote endpoint is down, the remote endpoint is unreachable, or because the remote network is unreachable.
catch (EndpointNotFoundException enfe)
{
secureSecretService.Abort();
// todo: Implement delay (backoff) and retry
}
// The following exception that is thrown when a server is too busy to accept a message.
catch (ServerTooBusyException stbe)
{
secureSecretService.Abort();
// todo: Implement delay (backoff) and retry
}
诚然，这是编写的一些普通代码。我目前更喜欢这个答案，并且在代码中没有看到任何可能导致问题的“hack”。
