WCF :: ServiceHost & AddServiceEndpoint: sono invertiti tipi Argomenti?

Question

Mentre sto cercando di imparare WCF, e sembra abbastanza straight-forward, mi è venuto attraverso una situazione strana ... almeno sembra strano per me.

Perché è che il ctor ServiceHost prende una classe concreta, e l'AddServiceEndpoint prende l'interfaccia, e non viceversa? sembra che il secondo è più logico dal punto di vista OOP.

Si consideri il seguente:

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

Così ora abbiamo Wanto creare un servizio "AnimalSound" che è possibile connettersi per ottenere il suono di un cane o un gatto tramite / AnimalSoundService / o del cane / 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");
...

Ma il codice di cui sopra non verrà compilato come per qualche motivo (s) Io non capisco, il ctor ServiceHost vuole la classe concreta (quindi o cane o gatto) e il punto finale vuole l'interfaccia.

Allora, qual è la ragione per cui non è viceversa, come mi sembra più naturale che la granularità endpoint più fine supporta una specifica implementazione (così si potrebbe colpire le implementazioni specifiche del contratto per ogni indirizzo dell'endpoint), mentre il ServiceHost più generale dovrebbe essere quello di accettare l'interfaccia?

A proposito, io non sto essendo pedantic..I sono solo onestamente cercando di capire come sono certo che sono io che mancava qualcosa qui.

Answer 1

Quando si crea il ServiceHost, si sta creando il servizio effettivo, quindi deve essere concreto.

I tuoi endpoint, d'altra parte, sono ciò che i vostri clienti vedono. Tu non vuoi necessariamente i vostri clienti di conoscere l'implementazione -. Dovrebbero solo ottenere la definizione di interfaccia

L'endpoind supporta una specifica implementazione, come dici tu: a seconda di quale quella che si usa quando si crea il ServiceHost. Lo scopo di endpoint, non è quello di fornire più implementazioni, ma per fornire più protocolli / binding per accedere una singola implementazione.

Se si desidera distinti servizi di cane e gatto, credo che avrete bisogno di due ServiceHosts, ciascuno con un endpoint NetNamedPipeBinding.

Answer 2

Capisco cosa pensare. Dal punto di vista OOP ha senso, ma non è una prospettiva di servizio. Un servizio è un gruppo di operazioni. Quel gruppo di operazioni è definito in un contratto. È possibile utilizzare le classi per modellare contratti di servizio, ma la maggior parte utilizzare le interfacce perché le interfacce sono un modello più diretta. MSDN ha un molto buona discussione di quei concetti.

Ricorda, tu non mi conosci e che non ti conosce. Ci scambiamo messaggi, non oggetti. Non voglio cani e gatti da voi. Non saprei cosa fare con un gatto o un cane che ti ha dato meno che non abbiamo un accordo preliminare. Tu mi dici quello che posso fare e che io chiamo i metodi su di voi per farlo. Ecco un buon articolo sui dati sulla parte interna contro i dati sulla parte esterna .

Answer 3

Non sono d'accordo un po 'con le altre risposte. Mentre sono tecnicamente corretto in un certo senso, mi sento la ragione più importante per questo sia il modo in cui è ha poco a che fare con nascondere l'implementazione o utilizzando le classi vs interfacce per definire contratti di servizio.

E 'molto più evidente perché è il modo in cui è se si prende in considerazione il fatto che una singola implementazione del servizio può esporre più endpoint. Ogni endpoint potrebbe, o non potrebbe, esporre un contratto diverso, e ognuno potrebbe essere esposta su un diverso vincolante, per tutto quello che sai.

Per esempio, si potrebbe avere un servizio che espone un contratto di un modo su MSMQ e un contratto a due vie su HTTP. O forse espone un contratto JSON su un URL e un XML uno su un altro.