WCF :: ServiceHost & AddServiceEndpoint: Est-types Arguments inversés?

Question

Alors que je suis en train d'apprendre WCF, et il semble assez droit vers l'avant, je suis tombé dans une situation étrange ... au moins il me semble étrange.

Pourquoi est-ce que le cteur ServiceHost prend une classe concrète, et la AddServiceEndpoint prend l'interface, et non vice versa? il semble que le dernier est plus logique du point de vue de la POO.

Considérez ce qui suit:

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

Alors maintenant, nous WANTO créer un service « AnimalSound » que vous pouvez vous connecter à obtenir le son d'un chien ou un chat via / AnimalSoundService / Chien ou / 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");
...

Mais le code ci-dessus ne compilera pas que pour une raison quelconque (s) Je ne comprends pas tout à fait, le cteur ServiceHost veut la classe concrète (donc soit chien ou chat) et le EndPoint veut l'interface.

Alors, quelle est la raison pour laquelle il est vice-versa, il me semble plus naturel que le critère d'évaluation de granularité plus fine prend en charge une implémentation spécifique (vous pouvez donc frapper les implémentations spécifiques du contrat par adresse de point final) tandis que le ServiceHost plus général devrait être celui d'accepter l'interface?

BTW, je ne suis pas pedantic..I suis juste essayer de comprendre honnêtement que je suis sûr que c'est moi qui a raté quelque chose.

Answer 1

Lorsque vous créez le ServiceHost, vous créez le service réel, donc il doit être concret.

Vos critères d'évaluation, d'autre part, sont ce que vos clients voient. Vous ne voulez pas nécessairement vos clients de connaître votre mise en œuvre -. Ils devraient simplement obtenir la définition d'interface

Le endpoind pris en charge par une mise en œuvre spécifique, comme vous le dites: quel que soit celui que vous utilisez lorsque vous créez le ServiceHost. Le but des points d'extrémité, est de ne pas fournir de multiples implémentations, mais pour fournir de multiples protocoles / liaisons pour accéder à une seule mise en œuvre.

Si vous voulez distincts des services de chiens et chats, je crois que vous aurez besoin de deux ServiceHosts, chacun avec un point final NetNamedPipeBinding.

Answer 2

Je vois ce que vous pensez. Du point de vue de la POO il est logique, mais ce n'est pas une perspective de service. Un service est un groupe d'opérations. Ce groupe d'opérations est défini dans un contrat. Vous pouvez utiliser des classes pour modéliser les contrats de service, mais la plupart des interfaces utiliser, car les interfaces sont un modèle plus direct. MSDN a très bonne discussion de ces concepts.

Rappelez-vous, vous ne me connaissez pas et je ne vous connais pas. Nous échangeons des messages, pas des objets. Je ne veux pas les chats et les chiens de vous. Je ne sais pas quoi faire avec un chat ou un chien, vous m'a donné moins que nous ayons un accord préalable. Vous me dites ce que je peux faire et j'appeler des méthodes sur vous pour le faire. Voici un bon article sur les données à l'intérieur par rapport aux données sur l'extérieur .

Answer 3

Je suis en désaccord un peu avec les autres réponses. Alors qu'ils sont techniquement corrects d'une manière, je me sens la plus importante raison pour que ce soit la façon dont il est a peu à voir avec la mise en œuvre cachant ou en utilisant des classes vs interfaces pour définir des contrats de service.

Il est beaucoup plus évident pourquoi il est la façon dont il est si l'on tient compte du fait qu'une mise en œuvre de service unique peut exposer plusieurs points de terminaison. Chaque critère d'évaluation pourrait, ou non, d'exposer un contrat différent, et chacun pourrait être exposé sur une autre liaison, pour tout ce que vous savez.

Par exemple, vous pourriez avoir un service qui expose un contrat à sens unique sur MSMQ et un contrat de deux voies sur HTTP. Ou peut-être il expose un contrat JSON sur une URL et un XML un sur l'autre.