設計SOA WCF Web服務時的最佳做法是什麼？

發出的操作合同，如：設計SOA WCF Web服務時的最佳做法是什麼？

[OperationContract] 
void Operation(string param1, string param2, int param3);

這可以被重新設計，以：

[MessageContract] 
public class OperationRequest 
{ 
    [MessageBodyMember] 
    public string Param1 { get; set; } 

    [MessageBodyMember] 
    public string Param2 { get; set; } 

    [MessageBodyMember] 
    public int Param3 { get; set; } 
} 

[MessageContract] 
public class OperationResponse 
{ 
} 

[OperationContract] 
OperationResponse Operation(OperationRequest request);

有一件事我喜歡的MessageContract的是，我得到多一點的明確控制的格式SOAP消息。

同樣，我可以寫幾乎相同的代碼，但使用DataContract：

我喜歡的DataContract

[DataContract] 
public class OperationRequest 
{ 
    [DataMember] 
    public string Param1 { get; set; } 

    [DataMember] 
    public string Param2 { get; set; } 

    [DataMember] 
    public int Param3 { get; set; } 
} 

[DataContract] 
public class OperationResponse 
{ 
} 

[OperationContract] 
OperationResponse Operation(OperationRequest request);

的一件事是我可以定義IsRequired，順序和名稱。

今天我期望唯一的消費者將是一個WCF客戶端。但是，我想盡可能設計合同並遵守SOA實踐。我不希望WCF指定我的SOAP，WSDL和XSD，而是希望XML定義WCF層，但使用WCF來生成這個WCF層，以便不向WCF添加任何自定義消息處理。我想遵循最常見的SOA XML約定，我認爲這可能是所有以小寫字母開頭的標籤 - 我是對的嗎？我想盡可能地容忍版本。

總是創建像這樣的請求和響應消息明智嗎？這三種格式中的哪一種促進了最佳SOA實踐？我應該更進一步並定義一個DataContract和一個MessageContract，其中MessageContract只包含DataContract？或者，如果我確實公開新類型（即不要將消息類型創建爲容器），我是否應該只使用DataContracts？

我知道一組加載的問題，但我試圖去了解它的核心，並且我不確定分離問題是否提供足夠的上下文來獲得我正在尋找的答案。

來源

2009-01-24 Victor

XML通常傾向於camelCased。 WSDL和XML架構對元素和屬性使用camelCasing，例如查看syntax和schema。

爲什麼SOAP的定義不同，我不知道，但它使用PascalCasing作爲元素，駝峯作爲屬性，請檢查here。

相似，大多數WS*規格（也許都是）使用PascalCasing作爲元素和屬性，請參閱here。 XML Schema對於它爲XML定義的類型的約定是不可知的。

Thomas Erl寫了很多關於SOA的重要書籍，包括「面向服務的體系結構」。在章節和他提供了許多典型事務的各個部分的XML的例子。它使用PascalCasing定義了XML Schema中的類型和對象成員，這與C＃的類和屬性命名的正常模式很好地匹配。因此WCF默認值已經與標準緊密匹配。

關於實際的消息命名，一些約定使用camelCasing，而其他約定使用PascalCasing，所以我的首選是匹配主語言需求，這在WCF案例中是PascalCasing。並且WCF默認值與請求和響應消息如何寫入的一些示例匹配，some examples here。

所以唯一未解決的問題是現在圍繞使用OperationContract,DataContract和/或MessageContract來標準化的基本問題。

定義DataContract只有當你有一個複雜類型（在XSD的說法）是有道理的，我傾向於認爲YAGNI（你是不是要去需要它）由特里指出的是正確的選擇，但Erl的似乎提出了一個更加流程密集的版本，所以我仍然不確定最佳方法作爲我的默認選擇（問題的主要部分）。

來源

2009-02-01 23:50:51 Victor

爲什麼這個回答社區wiki？這是一個很好的答案，vjrobinson應該得到他/她應得的聲望。 – 2009-08-21 15:21:02

我認爲它說實話取決於場景。如果你只是交換簡單的類型[即字符串]，OperationContract肯定是可以接受的。

當您想要修改消息格式時應該使用MessageContract，並且當您想要表達複雜類型（例如地址）時應該使用DataContract。

來源

2009-01-26 01:36:08

YAGNI想到這裏。

我說不要過於樂觀地期待未來。 WCF已經很好的SOA友好。我說，一般來說，堅持默認設置，並小心耦合，直到你有特定的需要做一些精心設計。

來源

2009-01-26 03:34:56

它總是一個最佳實踐，在操作合同中不會有多個參數，總是有一個包裝所有必需參數的類型，這將從長遠來看有所幫助。添加新的可選參數時，您的現有客戶端不會中斷。

我在一個業務集成團隊工作，我們經常與其他公司進行整合，並且從未看到過使用多個參數的Web服務調用。

來源

2009-06-26 05:47:30

與我們一樣的做法。我們將所有內容包裝成單個請求和響應對象。 – Junto 2012-03-14 16:20:41

設計SOA WCF Web服務時的最佳做法是什麼？

回答

相關問題