WCF::ServiceHost& AddServiceEndpoint：参数类型是否颠倒？

Question

当我尝试学习 WCF 时，它看起来很简单，但我遇到了一个奇怪的情况......至少对我来说似乎很奇怪。

为什么 ServiceHost ctor 采用具体类，而 AddServiceEndpoint 采用 Interface，而不是相反？ 从 OOP 的角度来看，后者似乎更符合逻辑。

考虑以下内容：

    [ServiceContract]
    interface IVocalAnimal
    {
        [OperationContract]
        string MakeSound();
    }
  ...      
  public class Dog : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Woof!");
     }
  }
 ...
 public class Cat : IVocalAnimal
  {
     public string MakeSound()
     {
        return("Meeooow!");
     }
  }

现在我们想要创建一个“AnimalSound”服务，您可以通过 /AnimalSoundService/Dog 或 /AnimalSoundService/Cat 连接该服务来获取狗或猫的声音，

...
Uri baseAddress = new Uri("net.pipe://localhost/AnimalSoundService");
ServiceHost serviceHost = new ServiceHost(typeof(IVocalAnimal), baseAddress);
serviceHost.AddServiceEndpoint(typeof(Dog), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Dog");
serviceHost.AddServiceEndpoint(typeof(Cat), new NetNamedPipeBinding(NetNamedPipeSecurityMode.None), "Cat");
...

但由于某种原因，上述代码将无法编译（ s）我不太明白，ServiceHost ctor 需要具体的类（因此 Dog 或 Cat），而 EndPoint 需要 Interface。

那么，反之亦然的原因是什么，因为在我看来，更精细的粒度端点支持特定的实现（因此您可以命中每个端点地址的合约的特定实现），而更通用的 ServiceHost 应该是更自然的接受接口？

顺便说一句，我并不是迂腐……我只是诚实地试图理解，因为我确信我在这里错过了一些东西。

Answer 1

当您创建 ServiceHost 时，您正在创建实际的服务，因此它必须是具体的。

另一方面，您的端点是您的客户所看到的。 您不一定希望您的客户知道您的实现——他们应该只获取接口定义。

正如您所说，端点确实支持特定的实现：无论您在创建 ServiceHost 时使用哪个实现。 端点的目的不是提供多个实现，而是提供多个协议/绑定来访问单个实现。

如果您想要不同的 Dog 和 Cat 服务，我相信您将需要两个 ServiceHost，每个 ServiceHost 都有一个 NetNamedPipeBinding 端点。

Answer 2

我明白你在想什么。 从面向对象编程的角度来看这是有道理的，但这不是服务的角度。 服务是一组操作。 该组操作是在合同中定义的。 您可以使用类来建模服务契约，但大多数使用接口，因为接口是更直接的模型。 MSDN 对这些概念有非常好的讨论。

记住，你不认识我，我也不认识你。 我们交换消息，而不是对象。 我不要你的猫和狗。 除非我们事先同意，否则我不知道如何处理你送给我的猫或狗。 你告诉我我能做什么，然后我调用你的方法来做到这一点。 这是一篇关于内部数据与外部数据的好文章 。

Answer 3

我不得不有点不同意其他答案。 虽然它们在某种程度上在技术上是正确的，但我认为最重要的原因是它的方式与隐藏实现或使用类与接口来定义服务契约无关。

如果考虑到单个服务实现可以公开多个端点这一事实，那么为什么会是这样就更明显了。 据您所知，每个端点可能会也可能不会公开不同的合约，并且每个端点都可以在不同的绑定上公开。

例如，您可能有一项服务公开通过 MSMQ 的单向协定和通过 HTTP 的双向协定。 或者它可能在一个 URL 上公开 JSON 契约，在另一个 URL 上公开 XML 契约。