WCF :: ServiceHost y AddServiceEndpoint: ¿Se han invertido los tipos de argumentos?

Question

Mientras yo estoy tratando de aprender WCF, y parece bastante sencillo, llegué a través de una situación extraña ... al menos eso parece extraño para mí.

¿Por qué es que la ctor ServiceHost toma una clase concreta, y la toma AddServiceEndpoint la interfaz, y no al revés? parece que el último es más lógico desde el punto de vista programación orientada a objetos.

Tenga en cuenta lo siguiente:

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

Así que ahora Wanto crear un servicio de "AnimalSound" que se puede conectar para obtener el sonido de un perro o un gato a través de / AnimalSoundService / o perro / 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");
...

Sin embargo, el código no se compilará como por algún motivo (s) que no entiendo muy bien, la ctor ServiceHost quiere la clase concreta (ya sea de manera perro o gato) y el extremo quiere que la interfaz.

Entonces, ¿cuál es la razón por la que no es viceversa, ya que me parece más natural que el punto final granularidad más fina es compatible con una aplicación específica (por lo que podría golpear las implementaciones específicas del contrato por dirección de punto final), mientras que el ServiceHost más general debe ser el que acepte la interfaz?

Por cierto, no estoy siendo pedantic..I sólo estoy sinceramente tratando de entender como estoy seguro de que es lo que se perdió algo aquí.

Answer 1

Cuando se crea el ServiceHost, que está creando el servicio real, por lo que debe ser concreta.

Sus criterios de valoración, por el contrario, son lo que sus clientes ven. Que no necesariamente quiere que sus clientes para conocer su aplicación -. Que sólo debe obtener la definición de la interfaz

El endpoind ¿son compatibles con una aplicación específica, como usted dice: lo que uno utiliza cuando se crea la ServiceHost. El propósito de los puntos finales, no es proveer múltiples implementaciones, sino proporcionar múltiples protocolos / fijaciones para acceder a una sola aplicación.

Si desea que los servicios de Perros y Gatos distintos, creo que necesitará dos ServiceHosts, cada uno con un punto final NetNamedPipeBinding.

Answer 2

Veo lo que pensar. Desde una perspectiva de programación orientada a objetos que tiene sentido, pero eso no es una perspectiva de servicio. Un servicio es un grupo de operaciones. Ese grupo de operaciones se define en un contrato. Puede utilizar las clases para modelar los contratos de servicio, pero la mayoría utilizan interfaces porque las interfaces son un modelo más directa. MSDN tiene una muy buena discusión de estos conceptos.

Recuerde, usted no me conoce y yo no te conozco. Que el intercambio de mensajes, no objetos. No quiero que los gatos y los perros de usted. No sabría qué hacer con un gato o un perro que me dio a menos que tengamos un acuerdo previo. Usted me dice lo que puedo hacer y llamar a métodos en que lo haga. He aquí una buen artículo en los datos en el interior frente a los datos en el exterior .

Answer 3

Tengo que discrepar un poco con las otras respuestas. Si bien son técnicamente correcta de una manera, siento que la razón más importante para que esto sea la forma en que se tiene poco que ver con ocultar la aplicación o el uso de clases frente a las interfaces para definir los contratos de servicio.

Es mucho más evidente por qué es como es, si se tiene en cuenta el hecho de que una sola implementación del servicio puede exponer varios puntos finales. Cada punto final podría o no podría, exponer a un contrato diferente, y cada uno puede estar expuesto en una unión diferente, por todo lo que sabes.

Por ejemplo, podría tener un servicio que expone un contrato de un camino de MSMQ y un contrato de dos vías a través de HTTP. O tal vez se expone un contrato JSON en una URL y un XML de uno sobre otro.