Question

我正在编写一个引用某些WCF服务的dll。 dll作为服务的网关运行，所有呼叫都通过它。可能会有并发呼叫。

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

此功能是否有一些示例或最佳做法。

Answer 1

我会创建与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就像更改配置设置一样简单。

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

Answer 2

为了回应Graymatter的回答，我看不出在调用暴露相同调用的服务包装器然后将调用转发给真实服务之间有什么区别，只是调用服务，假设一对一映射单个调用而不改变传输绑定。

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

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

那么如何包装服务端点取决于你想要包装服务的原因......

Web服务包装器

2 个答案: