WCF :: Servicehost & AddServiceEndpoint: Sind Argumente Typen umgekehrt?

Question

Während ich versuche, WCF zu lernen, und es scheint geradlinig genug, kam ich durch eine merkwürdige Situation ... zumindest ist es mir merkwürdig erscheint.

Warum ist es, dass der Servicehost Ctor eine konkrete Klasse nimmt, und die AddServiceEndpoint nimmt die Schnittstelle, und nicht umgekehrt? es scheint letztere logische aus einer OOP Sicht ist.

Beachten Sie Folgendes:

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

So, jetzt wanto wir einen „AnimalSound“ Service erstellen, die Sie den Klang der einen Hund oder eine Katze über / AnimalSoundService / Hund oder / AnimalSoundService / Katze zu erhalten verbinden kann

...
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");
...

Aber der obige Code wird nicht so aus irgendeinem Grunde zusammenstellen (s) Ich verstehe nicht ganz, die Servicehost Ctor will die konkrete Klasse (also entweder Hund oder Katze) und die EndPoint will die Schnittstelle.

Also, was ist der Grund, warum es nicht umgekehrt ist, wie es natürlicher mir scheint, dass die feineren Granularität Endpunkt eine spezifische Implementierung unterstützt (so könnten Sie spezifische Implementierungen des Auftrags pro Endpunkt-Adresse getroffen), während die allgemeine Servicehost sollte derjenige sein, der die Schnittstelle zu akzeptieren?

Btw, ich bin sein nicht pedantic..I ist nur ehrlich versuchen zu verstehen, wie ich bin sicher, dass ich es ist, der hier etwas übersehen.

Answer 1

Beim Erstellen der Servicehost, Sie den eigentlichen Dienst zu schaffen, so dass es konkret sein muss.

Ihre Endpunkte, auf der anderen Seite, sind das, was Ihre Kunden sehen. Sie müssen nicht unbedingt Ihre Kunden möchten, dass Ihre Implementierung wissen -. Sie sollten nur die Schnittstellendefinition erhalten

Die endpoind DOES eine spezifische Implementierung unterstützen, wie Sie sagen: je nachdem, was Sie verwenden, wenn Sie die Servicehost erstellen. Der Zweck von Endpunkten, ist nicht möglich, mehrere Implementierungen zu bieten, aber mehrere Protokolle / Bindungen, um eine einzelne Implementierung zugreifen zu können.

Wenn Sie verschiedene Hunde- und Katzen Dienste wollen, glaube ich, zwei ServiceHosts benötigen, die jeweils mit einem NetNamedPipeBinding Endpunkt.

Answer 2

Ich sehe, was Sie denken. Aus einer OOP Perspektive macht es Sinn, aber das ist kein Service Perspektive. Ein Dienst ist eine Gruppe von Operationen. Diese Gruppe von Operationen wird in einem Vertrag festgelegt. Sie können Klassen verwenden, um Dienstleistungsverträge zu modellieren, aber die meisten verwenden Schnittstellen, weil Schnittstellen ein direkteres Modell sind. MSDN hat eine sehr gute Diskussion dieser Konzepte.

Denken Sie daran, Sie kennen mich nicht, und ich kenne dich nicht. Wir tauschen Nachrichten, keine Objekte. Ich will nicht, Katzen und Hunde von Ihnen. Ich wüsste nicht, was mit einer Katze zu tun oder einen Hund, den Sie mir gegeben haben, es sei denn wir vorherige Zustimmung haben. Sie sagen mir, was ich tun kann, und ich rufe Methoden auf Sie, es zu tun. Hier ist ein guter Artikel auf Daten auf der Innenseite gegen Daten auf der Außenseite .

Answer 3

muss ich mit den anderen Antworten ein wenig widersprechen. Während sie technisch korrekt in einer Art und Weise sind, fühle ich mich den wichtigsten Grund dafür ist die Art und Weise zu sein, es hat wenig mit Ausblenden der Implementierung oder mithilfe von Klassen vs Schnittstellen zu tun ist, um Dienstleistungsverträge zu definieren.

Es ist viel mehr offensichtlich, warum es so, wie es ist, wenn Sie berücksichtigen die Tatsache, dass eine einzelne Service-Implementierung mehr Endpunkte aussetzen kann. Jeder Endpunkt könnte, oder auch nicht, einen anderen Vertrag aussetzen, und jeder könnte auf einer anderen Bindung ausgesetzt werden, für alles, was Sie wissen.

Zum Beispiel könnten Sie eine Dienstleistung, die einen Einweg Vertrag über MSMQ und einen Zweiweg-Vertrag über HTTP aussetzt. Oder vielleicht ist es macht einen JSON Vertrag über eine URL und eine XML einer auf der anderen.