在面向服务的架构中定义方法签名以进行服务调用的最佳实践是什么？

Question

在面向服务的架构中开发应用程序时定义服务调用原型/签名的最佳实践是什么。

例如，我想创建服务调用来发送电子邮件。

假设我的域层中有以下对象

 [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;}

  }

我应该创建像这样的服务方法签名吗？

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

public bool SendEmail(Email myEmail){//My Logic} 我倾向于第一种选择。（话虽如此，我知道对象是否过于复杂，而不是传递整个对象本身才有意义。）

Answer 1

不幸的是，在这种情况下，第二个选项不太清楚，这是因为您的

Email class

。

假设我要调用你的方法。你让我传递

Email

 类的实例。我查看班级合同并找到 7 个属性。

而且，我如何知道哪些参数是强制性的，哪些参数是可选的？从文档中？如果我必须查阅文档才能正确使用 API，这不是最干净的设计。

我宁愿重构您的 Email 类，将其称为

EmailRequest

，并删除所有这些可选参数，然后如果您需要将其用作服务的 

return

 值，我将创建另一个类 

EmailResponse。

Answer 2

我也投票支持方法#2。

既然您提到了“面向服务的架构”，您应该创建一个

DataContract

 来完全控制客户所看到的内容。

在这里，序列化是选择加入的，因此“未使用的属性”不会通过网络发送。

此外，您还可以获得其他好处，例如控制序列化成员的顺序、指定字段是否为必填、自定义名称、版本控制等。它只是让事情对客户来说变得显而易见。

此外，据说

DataContractSerializer

 比 

XmlSerializer

 快 10%。有关 

this 博客的更多详细信息，尽管我不确定方法 #1（原始类型）是否会使用 XmlSerializer

 或 

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

采用 OOP 方式总是更好。如果电子邮件类别过多，请尝试分析并定义另一个解决方案。像这样

   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;}

      }

并使用这样的服务

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

Answer 4

两个都写怎么样？只需拥有第一个，调用第二个？

Answer 5

我会让你的

Email

 对象成为一个 [DataContract] 并选择选项二。我认为您不希望一种服务方法有那么多参数。

Answer 6

SOA 的重要方面之一是合同，因此我真的反对用不需要的数据和细节来混乱它，这会导致它快速恶化（呃）。

channs 提供的选项非常好，因为它专注于显式和详细地定义合约，但我还将用于合约目的的类与内部使用的类分开，以解耦和隐藏内部实现细节（我在

Edge Component 图案中的详细信息）

Answer 7

该软件已授权给我，并通过 json 许可证文本类型符号 { 自 1998 年起就有该软件。ross nicholas oneil thomas

[电子邮件受保护] [电子邮件受保护] github 域名所有者