Quelle est la meilleure pratique pour définir la signature d'une méthode dans une architecture orientée service pour un appel de service ?

Question

Quelle est la meilleure pratique pour définir un prototype/signature d'appel de service lors du développement d'une application dans une architecture orientée service.

Par exemple, je veux créer un appel de service pour envoyer un courriel.

Disons que j'ai l'objet suivant dans ma couche de domaine

 [datacontract]
public class Email
{
      public string To { get; set; }
      public string From { get; set; }
      public string Message { get; set; }
      public string Subject { get; set; }

      //I am not going to use this properties in send email method
      public string OtherProp1 {get; set;}
      public string OtherProp2 {get; set;}
      public string OtherProp3 {get; set;}

  }

Dois-je créer une signature de méthode de service comme

   public bool SendEmail(string from,string to, string subject,string message){//My Logic}}

O

   public bool SendEmail(Email myEmail){//My Logic}

Je penche pour la première option (cela dit, je sais que si l'objet est trop complexe, il est plus logique de passer l'objet lui-même).

Answer 1

L'un des aspects importants de l'architecture orientée services (SOA) est le contrat, et je ne voudrais surtout pas l'encombrer de données et de détails inutiles qui le détérioreront rapidement.

L'option proposée par channs est assez bonne car elle se concentre sur la définition du contrat de manière explicite et détaillée, mais je séparerais également les classes utilisées pour les besoins du contrat des classes utilisées en interne afin de découpler et de cacher les détails de l'implémentation interne (j'explique cela en détail dans l'article intitulé Composant du bord modèle)