在面向服務的架構中爲服務調用定義方法簽名的最佳實踐是什麼？

在面向服務的體系結構中開發應用程序時定義服務調用原型/簽名的最佳實踐是什麼？在面向服務的架構中爲服務調用定義方法簽名的最佳實踐是什麼？

例如，我想創建服務調用來發送電子郵件。

讓我們說，我已經在我的領域層以下對象

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

我對第一個選項扶着服務方法的簽名。（說過我知道對象是複雜的方式，而不是傳遞整個對象本身的意義。）

來源

2012-08-15 A P

你的意思是'公共bool'？ – 2012-08-15 19:11:36

這對於[programmers.se]來說是一個很好的問題，而不是[so]。 – 2012-08-15 19:22:31

不幸的是服務，第二個選項是在這種情況下，不太清楚，這是因爲你的Email class的。

假設我打電話給你的方法。你讓我通過Email課程的一個實例。我去上課合同，並找到7個屬性。

而且，我該如何知道哪些參數是必需的，哪些是可選的？從文檔？如果我必須查閱文檔以正確使用API，則不是最乾淨的設計。

我寧願重構你的Email類刪除了所有這些可選參數來調用它EmailRequest，然後如果你需要使用它作爲服務的返回值我又創建另一個類EmailResponse。

來源

2012-08-15 19:27:46

如何寫兩者？只要有第一個，打電話給第二個？

來源

2012-08-15 19:12:41

您必須重命名一個，因爲WSDL不允許重載操作名稱。 – 2012-08-15 19:20:49

如果您在OperationContract上使用name屬性，則可以重載服務方法。我並不是說它是最優的/簡單的，但客戶端可以利用重載的方法 – 2012-08-15 19:35:33

我瞭解WSDL不允許操作被重載，我從來沒有說過重它們。我會創造兩個，在這種情況下額外的努力是微不足道的。 – 2012-08-21 11:53:49

我會讓你的Email對象成爲[DataContract]並且使用選項2。我認爲你不需要一個服務方法的許多參數。

來源

2012-08-15 19:15:14

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

來源

2012-08-15 19:18:46

我也爲方法＃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;}  
}

來源

2012-08-15 19:40:21 Channs

SOA的一個重要方面是合同，所以我真的會投票反對與不需要的數據和細節，這將導致其性能下降速度快（ER）弄亂了。

channs提供的選項非常好，因爲它專注於明確詳細地定義契約，但我還將用於合同目的的類與內部使用的類分開並隱藏內部實現細節（I在Edge Component模式中詳細解釋這一點）

來源

2012-08-19 19:15:40

在面向服務的架構中爲服務調用定義方法簽名的最佳實踐是什麼？

回答

相關問題