Web服務：字符串參數或複雜的類型參數

是或多或少可以接受的（即標準）來創建這些方法簽名一個公開暴露的網絡服務：Web服務：字符串參數或複雜的類型參數

ThisMethodDoesSomething(ComplexType param) 

ThisMethodDoesSomethingElse(AnotherComplexType param)

或者這樣：

ThisMethodDoesSomethingAndSomethingElse(string xml)

正在執行的操作取決於將XML字符串傳遞給單個全部執行的方法嗎？我一直和前者一起工作，但我的同事更喜歡後者，我試圖在開始一個新項目之前權衡兩種策略的優缺點。公衆更容易接受和更容易合作，爲什麼？

來源

2010-08-16 Brad Wesley

我更喜歡（因爲沒有這個標準，所以我更喜歡這個操作詞），一個複雜的XML字符串解釋了這個動作。你可以從my open-source project看到這個。

一些我喜歡它的原因......

你的行爲是一種解釋型語言，可以彎曲。
動作可以複合到單個網絡旅程中。
XML允許擴展功能集，同時不會破壞過去的功能。
XML層次結構允許對服務器端的操作採取操作。

來源

2010-08-16 15:37:42 dacracot

感謝您的回覆。從表面上看，這只是我感覺不對，有點像：爲什麼我應該在對象執行時在程序中傳遞int或double？對象更靈活，對嗎？我不傾向於這種方法的另一個原因是Method（字符串）不像Method（int）或Method（otherType）那樣自成文檔。你的觀點1和3是有意義的。你能否擴展點2和點4？ – 2010-08-16 16:47:48

以前我會優先考慮後者，因爲我不確定，如果在跨平臺的情況下，每個SOAP客戶端都能夠正確使用複雜類型。所以我認爲一個SOAP調用，只需要返回（XML-）字符串就不會讓我頭疼。與此同時，我體驗到，第一種方法通常沒有問題，至少對於.NET與JAVA/AXIS進行互操作，反之亦然。儘管如此，我仍然在關注複雜類型的複雜性。

我假設ThisMethodDoesSomething()和ThisMethodDoesSomethingElse()是原子操作嗎？如果不是這種情況（ThisMethodDoesSomethingElse()要求致電ThisMethodDoesSomething()執行），第一種方法是不行。

來源

2010-09-14 10:46:39 huo73

你的問題聽起來像是乍一看粗粒紋和細粒度界面的問題。另一方面，如果你知道我的意思，我覺得第二種方法正在粗放到極端。你失去了所有類型的檢查。你讓實現變得非常困難 - 如果在後臺代碼中需要很多案例來真正弄清楚請求是關於什麼的，你需要很多。該方法將返回什麼？我猜如果你只是得到一個字符串作爲參數，你會返回另一個字符串。由於它是一個字符串，我猜它是一個XML文檔的字符串表示形式，所以您必須將解析部分作爲您的支持代碼。隨着界面變得越來越大，我認爲這些會變成上帝的方法。該名單繼續:)

作爲一個方面說明，不要認爲我主張非常細粒度的接口。兩者之間必須保持平衡。對我來說，經驗法則就是始終傳遞一個元素。

來源

2010-09-16 09:42:27 Selim

我通常會創建一個xml模式來描述將構成我的界面的消息。然後，使用xsd類生成器（如Castor或Microsoft xsd.exe）創建我的實現類。

來源

2010-09-21 20:14:53

我永遠不會發送XML字符串。首先，「XML」與「字符串」不同。他們不遵循相同的規則。

任何合理客戶端可以接受的複雜類型，包括原始類型並列出或基本類型數組，遞歸（C＃語法）的：

public class ComplexType1 
{ 
    public int IntegerProperty {get;set;} 
    public int[] ArrayOfIntegers {get;set;} 
    public List<int> ListOfIntegers {get;set;} // Same as ArrayOfIntegers 
} 

public class ComplexType2 
{ 
    public ComplexType1 CT1 {get;set;} 
    public List<ComplexType1> LCT1 {get;set;} 
}

坦率地說，不能用類似的處理的任何客戶機以上值得退休。

來源

2010-09-21 20:20:44

Web服務：字符串參數或複雜的類型參數

回答

相關問題