6

我正在编写一个引用某些 WCF 服务的 dll。该 dll 充当服务的网关，所有调用都通过它。可能会有并发调用。

我已经引用了该服务，但现在我无法决定如何正确编写包装函数。

此功能是否有一些示例或最佳实践。

4

2 回答 2

5

我会制作与 Web 服务接口匹配的包装器。包裹所有暴露的对象也是一个好主意。基本上创建一个代理。我发现对这类事情真正有用的是创建一个与 API 匹配的接口并实现它。这样，您可以创建 DLL 的虚拟版本进行测试，而无需与 WCF 调用相关的开销（或潜在成本）。如果您将来需要用备用提供程序替换 WCF 调用，它也会变得更简单。

例如，假设我们有一个用于处理付款的外部提供商的 WCF 服务。像这样的东西：

void ProcessPayment(float amount);

我们可以轻松地将其挂接到我们的代码中。问题是对接口的简单更改将导致我们不得不在引用代码的任何地方进行更改。如果我们将提供者更改为其他人，即使界面几乎相同，也需要这样做。添加类似简单界面的内容：

interface IPaymentProvider
{
    void ProcessPayment(float amount);
}

将我们的代码与 WCF 服务完全分离。我们可以很容易地构建一个这样的类：

class PaymentProviderAWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call the WCF service
    }
}

我们可以使用像 Spring.NET 这样的工厂或依赖注入框架动态加载。更改为提供者 B 就像创建新包装器一样简单：

class PaymentProviderBWrapper : IPaymentProvider
{
    void ProcessPayment()
    {
        // Call provider B's Native DLL
    }
}

将您的代码从提供者 A 切换到 B 就像更改配置设置一样简单。

即使我们将库直接编译到我们的代码中，我们需要做的只是更改构造逻辑以使用新库。我们的应用程序的其余部分根本不会改变。只是一个简单的重新编译。

于 2012-04-30T12:09:53.870 回答
2

为了响应 Graymatter 的回答，我看不出调用服务包装器之间的区别是什么调用并且传输绑定没有变化。

您首先要创建包装器的唯一原因是以某种方式公开的接口本身不能满足您的要求。您可能想要这样做有几个原因，但有几个常见的原因：

  1. 协议转换 - 服务未根据您的需要通过正确的传输绑定公开
  2. 服务组合——接口操作过于细化，不代表业务级别的操作。
  3. 身份验证 - 也许您需要在您正在使用的端点之上的身份验证层。

那么如何包装服务端点取决于你为什么要包装服务......

于 2012-04-30T12:40:21.130 回答