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

Malheureusement, la deuxième option est moins claire dans ce cas, et ce en raison de votre Email class .

Supposons que je doive appeler votre méthode. Vous me faites passer une instance de l'objet Email la classe. Je vais dans le contrat de la classe et je trouve 7 propriétés.

Et, comment suis-je censé savoir quels paramètres sont obligatoires et lesquels sont facultatifs ? En consultant la documentation ? Ce n'est pas une conception très propre si je dois consulter la documentation pour utiliser correctement l'API.

Je préférerais refactoriser votre classe Email pour l'appeler EmailRequest avec tous ces paramètres optionnels enlevés et ensuite je créerais encore une autre classe EmailResponse si jamais vous avez besoin de l'utiliser comme retourner la valeur d'un service.

Answer 2

Je vote moi aussi pour l'approche n° 2.

Puisque vous avez mentionné une "architecture orientée services", vous devriez créer une DataContract pour avoir le contrôle total de ce que vos clients voient.

Ici, la sérialisation est facultative, de sorte que les "propriétés inutilisées" ne seront pas envoyées par câble.

De plus, vous bénéficiez d'autres avantages comme le contrôle de l'ordre des membres sérialisés, la spécification des champs obligatoires ou non, les noms personnalisés, le versionnage, etc. Cela rend les choses évidentes pour les clients.

En outre, le DataContractSerializer est censé être 10% plus rapide que le XmlSerializer . Plus de détails sur ce bien que je ne sois pas sûr que l'approche #1 (types primitifs) utiliserait XmlSerializer o DataContractSerializer .

[DataContract(Name="MyEmail", Namespace="http://contoso.org/soa/datacontracts")]
public class Email
{
  [DataMember(Name="ToField", IsRequired=true, Order=0]
  public string To { get; set; }

  [DataMember(Name="FromField", IsRequired=false, Order=1]
  public string From { get; set; }

  [DataMember(Name="MessageField", IsRequired=true, Order=2]
  public string Message { get; set; }

  [DataMember(Name="SubjectField", IsRequired=false, Order=3]
  public string Subject { get; set; }

  public string OtherProp1 {get; set;}
  public string OtherProp2 {get; set;}
  public string OtherProp3 {get; set;}    
}

Answer 3

Il est toujours préférable d'opter pour la méthode OOP. Si la classe email est excessive, essayez d'analyser et de définir une autre solution. Comme ceci

   public class Email
    {
          //everything needed for service is extracted in another class
          public EmailAddressDetails {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;}

      }

et utiliser le service comme ceci

   public bool SendEmail(EmailAddressDetails email){//My Logic}}

Answer 4

Pourquoi ne pas écrire les deux ? Et simplement avoir le premier, appeler le second ?

Answer 5

Je ferais de votre Email un [DataContract] et choisir l'option 2. Je pense que vous ne voulez pas avoir autant de paramètres pour une méthode de service.