代码之家 › 专栏 › 技术社区 › stack72

调用WCF服务的多个方法

principles design-patterns wcf

stack72 · 技术社区 · 14 年前

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

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

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个不同的地方添加日志记录工作

有没有人能告诉我在重用代码的时候我是如何变得更加足智多谋的

谢谢

保罗

1 回复 | 直到 14 年前

Ondrej Tucny 14 年前

我将使用一些通用的、可配置的异常处理组件,它允许基本的异常处理处理(如日志记录、重新抛出等)与实际的处理位置分离。这种组件的一个例子是微软的 Exception Handling Application Block .

然后你可以得到这样的代码:

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

哪里 CloseIfNeeded 表示封装WCF通道关闭逻辑的自定义扩展方法,以及 Handle 异常方法调用异常处理机制,传入应在此位置应用的异常策略的名称。

在大多数情况下,您可以将异常处理逻辑简化为一行或两行代码,这会给您带来以下好处:

异常处理行为(策略)的即时可配置性
可扩展性,自定义异常处理程序绑定到特定类型的异常和异常策略
更好的代码可管理性和可读性

推荐文章

Dinesh · 将带有wsHttpBinding的WCF服务迁移到Azure应用程序服务

3 年前

Ehsan Akbar · 当请求被激发时,WCF请求时间会增加

6 年前

Gans · 具有多操作合约的WCF Rest服务

6 年前

Charles Chen · 从IIS应用程序打开命名管道通道时,WCF访问被拒绝

7 年前

Menno van den Heuvel · Bing Ads API:中的端点配置。配置

7 年前

Moelgaard · NLog中的IIS应用程序名称。配置

7 年前

Hasan Zubairi · 来自angular的WCF Post Json

7 年前

NealWalters · BizTalk EndpointBehavior未显示-安装博客BizTalkRESTHandler

7 年前

Kerwen · WCF服务调用异步函数

7 年前

A.Pissicat · 相当于用户IP地址的HttpContext[重复]

7 年前