2010-08-16 5 views
6

Ist es mehr oder weniger akzeptabel (dh Standard) einen öffentlich-exponierten Webservice mit dieser Methode Signaturen zu erstellen:Web Service: Einzelsaite Parameter oder komplexer Typ Parameter

ThisMethodDoesSomething(ComplexType param) 

ThisMethodDoesSomethingElse(AnotherComplexType param) 

Oder diesen:

ThisMethodDoesSomethingAndSomethingElse(string xml) 

Woher die durchgeführte Operation hängt von der XML-Zeichenfolge ab, die an eine einzelne Do-It-All-Methode übergeben wird? Ich bin immer mit dem Ersten gegangen, aber ein Kollege von mir bevorzugt den Letzteren und ich versuche, Vor- und Nachteile beider Strategien abzuwägen, bevor wir ein neues Projekt beginnen. Welcher akzeptiert und einfacher für die Öffentlichkeit und warum?

Antwort

0

Ich bevorzuge (und das ist das operative Wort, bevorzugen, denn es gibt keinen Standard dafür) eine komplexe XML-Zeichenfolge, die die Aktion erläutert. Sie können dies von my open-source project sehen.

Einige der Gründe, warum ich es lieber ...

  1. Ihre Aktionen sind eine interpretierte Sprache, die sich verformen kann.
  2. Aktionen können zu einer einzelnen Netzwerkauslösung zusammengefasst werden.
  3. XML ermöglicht die Erweiterung des Feature-Sets, ohne dass frühere Features unterbrochen werden.
  4. Die XML-Hierarchie ermöglicht Aktionen, die auf Aktionen serverseitig wirken.
+0

Danke für die Antwort. Auf der Oberfläche fühlt sich das einfach falsch an, so etwas wie: Warum sollte ich in meinem Programm int oder double übergeben, wenn Objekt funktioniert? Objekt ist flexibler, oder? Der andere Grund, warum ich nicht zu diesem Ansatz tendiere, ist Methode (String) ist nicht so selbstdokumentieren wie Methode (int) oder Methode (otherType). Ihre Punkte 1 und 3 ergeben Sinn. Können Sie die Punkte 2 und 4 ein wenig erweitern? –

1

Früher hätte ich das letzteres lieber gewesen, weil ich nicht sicher war, ob in Cross-Plattform-Situation würde jeder SOAP-Client in der Lage sein, um richtig die komplexen Typen zu konsumieren. Also dachte ich, ein SOAP-Aufruf, der einfach nimmt und zurückgibt (XML-) Strings wird mir keine Kopfschmerzen bereiten. In der Zwischenzeit habe ich festgestellt, dass es mit dem ersten Ansatz zumindest für .Net keine Interoperabilität mit JAVA/AXIS und umgekehrt gibt. Ich schaue immer noch zu, um den komplexen Typ nicht zu komplex zu machen. Ich nehme an, dass ThisMethodDoesSomething() und ThisMethodDoesSomethingElse() atomare Operationen sind? Wenn dies nicht der Fall ist (ThisMethodDoesSomethingElse() erfordert einen Aufruf an ThisMethodDoesSomething() auszuführen), ist der erste Ansatz ein Nein.

0

Ihre Frage klingt für mich wie eine Frage grobkörniger vs feinkörniger Oberflächen auf den ersten Blick. Auf der anderen Seite habe ich den Eindruck, dass der zweite Ansatz grobkörnig ist, wenn man weiß, was ich meine. Sie verlieren alle Typprüfungen. Sie machen die Implementierung sehr schwierig - Sie müssten eine Menge Fälle innerhalb des Backing-Codes benötigen, um herauszufinden, worum es bei der Anfrage geht. Was wird die Methode zurückgeben? Ich vermute, wenn Sie nur eine Zeichenfolge als Parameter erhalten, werden Sie eine andere Zeichenfolge zurückgeben. Da es sich um einen String handelt und ich vermute, dass es sich um eine String-Repräsentation eines XML-Dokuments handelt, müssen Sie den Parsing-Teil Ihres Backing-Codes machen. Wenn die Schnittstelle größer wird, gehe ich davon aus, dass sich diese in Gott-Methoden verwandeln werden. Die Liste geht weiter :)

Als eine Randnotiz, glaube nicht, dass ich befürworte sehr feinkörnige Schnittstellen. Es muss ein Gleichgewicht zwischen den beiden geben. Eine Faustregel für mich wäre, immer ein Element zu übergeben.

0

Ich erstelle normalerweise ein XML-Schema, um die Nachrichten zu beschreiben, die meine Schnittstelle bilden werden. Dann benutze ich einen xsd zum Klassengenerator wie Castor oder Microsoft xsd.exe und erstelle meine Implementierungsklassen.

2

Ich würde niemals eine XML-Zeichenfolge senden. Zunächst einmal ist "XML" nicht dasselbe wie "String". Sie folgen nicht den gleichen Regeln.

kann Jeder vernünftige Client einen komplexen Typ, bestehend aus primitiven Typen und Listen oder Arrays von primitiven Typen, rekursiv (C# Syntax) akzeptieren:

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

jeder Client Ehrlich gesagt, die mit so etwas wie das nicht umgehen kann oben verdient es, im Ruhestand zu sein.