0

我有一个类可以处理我的应用程序中与我的 WCF 服务的所有交互，似乎 MSDN 说在 WCF 中使用 Using)_ 语句是不好的 - 我可以看到为什么这是不好的并同意它 (http:/ /msdn.microsoft.com/en-us/library/aa355056.aspx)

我的问题是他们建议的实现方法将意味着我有 10 个方法 [作为我的服务中的 10 个公共方法]，它们将具有相同的结构代码，这当然不遵循 DRY 原则 - 代码看起来类似于以下：

try
{
    results = _client.MethodCall(input parameteres);
    _client.Close();
}
catch (CommunicationException)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
}
catch (TimeoutException)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
}
catch (Exception ex)
{
    if (_client != null && _client.State != CommunicationState.Closed)
    {
        _client.Abort();
    }
    throw;
}

这还没有任何日志记录，但当然，当我开始记录它时，我将不得不在近 10 个不同的地方添加日志记录工作

有人对我如何在重用代码方面更加足智多谋有任何建议吗

谢谢

保罗

4

1 回答 1

5

我会使用一些通用的、可配置的异常处理组件，它允许基本的异常处理处理（如日志记录、重新抛出等）与实际处理位置分离。此类组件的一个示例是 Microsoft 的异常处理应用程序块。

然后你可能会得到这样的代码：

try
{
    results = _client.MethodCall(input parameteres);
    _client.Close();
}
catch (Exception ex)
{
    _client.CloseIfNeeded();
    if (!ex.Handle("Wcf.Policy")) throw;
}

whereCloseIfNeeded表示自定义扩展方法，封装了 WCF 通道关闭逻辑，Handle异常方法调用异常处理机制，传入要应用在这个地方的异常策略的名称。

在大多数情况下，您可以将异常处理逻辑减少到体面的一两行代码，从而为您带来以下好处：

  • 异常处理行为（策略）的即时可配置性
  • 自定义异常处理程序的可扩展性绑定到特定类型的异常和异常策略
  • 更好的代码可管理性和可读性
于 2010-10-06T11:19:28.317 回答