不使用WCF调用WCF服务-好还是坏的实践？

Question

我正在为一个应用程序开发面向服务的架构，并希望服务既可以通过WCF公开，也可以通过一个简单的库使用。理想情况下，我希望能减少重复代码。

从概念上讲，这对应于：

客户端 => WCF服务 => 服务库（实际实现）

或者

客户端 => 服务库（实际实现）

基于客户端所在位置（本地或远程）。

以下是一个简单的示例：

[ServiceContract]
public interface ICalculator
{
    [OperationContract]
    int Add(int a, int b);
}

public class Calculator : ICalculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

public class CalculatorFactory
{
    public static ICalculator CreateCalculator()
    {
        return new Calculator();
    }
}

我的客户端应用程序执行了以下操作

int result = CalculatorFactory.CreateCalculator().Add(1,2);

或者

int result = IChannelFactory<ICalculator>().CreateChannel().Add(1,2);

根据是本地还是远程，调用WCF注释代码而不使用WCF是否是一种不良实践？

其他评论：

• 我意识到在所有情况下都可以使用WCF，并使用NamedPipes来托管本地连接的服务。 为了简单起见，如果可能的话，我想避免这样做。
• 上述方法的替代方案是在服务库中基本上复制ICalculator接口，并更改WCF服务实现以包含CalculatorFactory.CreateCalculator().Add(1,2)。考虑到我希望接口保持相同，这似乎是很多开销。

- Travis

---

第二个不是资源泄漏吗，因为代理需要关闭吗？ - alternative

这与问题并不完全相关 - 上面只是我大脑中随意编写的示例代码。问题更多地涉及概念性内容。 - Travis

Answer 1

您可以创建和使用带有WCF注释的类，除非您开始使用一些与WCF相关的功能，例如OperationContext等，否则在本地没有任何问题。

通常，这通常以不同的方式抽象出来：

客户端 => 服务代理 => 商业服务

或者

客户端 => 服务代理 => WCF服务 => 商业服务

客户端本身不知道服务是本地还是远程的。服务代理是客户端组件，它根据其实现要么创建本地服务实例，要么调用远程WCF服务，后者又创建业务服务实例。服务代理可以被注入为客户端依赖项，这将使您的应用程序非常易于配置。此外，您可以在服务代理上公开不同的接口（与业务服务实现相同），如果您希望WCF服务和代理使用不同的接口，则可以这样做。

如果您决定始终使用WCF服务，包括本地调用，请勿使用NamedPipes。命名管道用于同一机器上的进程间通信。如果要在同一进程中使用通信，请改用 NullTransport 或 Local Channel 。仍然比直接调用性能差。

- Ladislav Mrnka

---

+1 用于本地通道——我不知道那个。我想上面的 CalculatorFactory 可以被视为 ServiceAgent；CreateCalculator 方法可以仅返回一个计算器实例，也可以返回客户端通道。我的主要愿望是由客户端实现者做出本地/远程决策。 - Travis