Was ist der richtige Weg, um Eingabeparameter mit komplexen Typen für einen C# .net 2.0 WebService zu codieren?

Question

Ich baue gerade eine neue Version von Webservice, die meine Firma bereits anbietet. Der aktuelle Webservice hat einen Eingabeparameter vom Typ string. In dieser Zeichenfolge wird ein vollständiges XML-Dokument übergeben. Wir validieren diese Zeichenfolge dann gegen ein xsd (das gleiche xsd, das dem Konsumenten gegeben wird). Es sieht ungefähr so ​​aus:

[WebMethod] 
public bool Upload(string xml) 
{ 
    if (ValidateXML(xml)) 
    { 
     //Do something 
    } 
} 

Ich baue die nächste Version dieses Dienstes. Ich hatte den Eindruck, dass die Übergabe eines XML-Dokuments als String nicht der richtige Weg ist. Ich dachte, dass mein Dienst wie folgt aussehen würde:

[WebMethod] 
public bool Upload(int referenceID, string referenceName, //etc...) 
{ 
    //Do something 
} 

Dieses Problem, das ich habe ist, dass in Wirklichkeit eine große Menge an Eingangsparameter sind und einige von ihnen sind komplexe Typen. Zum Beispiel muss die Upload-Methode ein komplexes Objekt namens "Zuweisung" aufnehmen. Dieses Objekt besteht tatsächlich aus mehreren Ganzzahlen, Dezimalwerten, Strings und anderen komplexen Objekten. Sollte ich den Webservice wie folgt aufbauen:

Oder gibt es einen anderen Weg, dies zu tun?

Hinweis: Dieses Zuweisungsobjekt hat eine Hierarchie in der xsd, die für den alten Dienst bereitgestellt wurde.

Könnte es sein, dass der ursprüngliche Dienst nur XML zur Bekämpfung dieses Problems verwendet hat? Gibt es eine bessere Möglichkeit, komplexe Typen in einen Webservice einzubinden?

Hinweis: Dies ist ein C# 2.0 Webservice.

Answer 1

Ich würde wahrscheinlich die XSD mit "xsd.exe" -Tool verwenden, um ein XML Serializable-Objekt zu erstellen. Dann können Sie mit Objekten statt String-Parametern umgehen. Es gibt Ihnen auch die Möglichkeit, die Signaturen des WebService nicht zu ändern.

Wenn Sie die XSD ändern, um einen weiteren Parameter hinzuzufügen, müssen Sie die Klasse mit dem Tool XSD.exe erneut erstellen. Nutzen Sie Teilklassen hier. Trennen Sie Ihre automatisch generierte Klasse von Ihrer Geschäftslogik. Auf diese Weise können Sie die Klassendefinition erneut erstellen, wenn sich die XSD-Datei so oft ändert, wie Sie möchten, ohne jedoch Ihre Geschäftslogik zu berühren.

XML Serialization in the .NET Framework

Wenn Sie 3.5 verwendet haben, können Sie auch Ihre XML-Parameter schnell zu analysieren, LINQ to XML verwenden.

Answer 2

Solange Ihre komplexen Typen in irgendeiner Weise XmlSerializable sind, sollten Sie keine Probleme mit diesen komplexen Typen haben. Lassen Sie den Rahmen das schwere Heben für Sie erledigen. Es wird eine geeignete WSDL generieren und die Daten werden serialisiert, anstatt sich um die Validierung und Serialisierung kümmern zu müssen.

[Serializable] ist dein Freund.

Answer 3

Jon, um Ihre Frage zu beantworten zuerst: Wenn Ihre Clients auf mehreren Plattformen sind (oder zumindest nicht alle auf .NET), ist der beste Ansatz die sogenannte "WSDL-first". Definieren Sie die Dienstschnittstelle in WSDL - hier werden Dienste und Methoden definiert. WSDL referenziert eine Gruppe von XSDs, die die datenhaltenden Objekte definieren, die an diese Methoden übergeben und von diesen zurückgegeben werden. Sie können C# - oder Java-Code aus WSDL/XSDs generieren.

Zurück zu Ihrer ursprünglichen Frage.Aus Gründen der Wartbarkeit besteht die beste Vorgehensweise darin, für jede Webmethode Request- und Response-Klassen zu definieren und Strings, Bools und Integer niemals direkt zu übergeben. Zum Beispiel

// in your Web service class 
[WebMethod] 
public UploadResponse Upload(UploadRequest request) { 
    ... 
} 
... 

[Serializable] 
public class UploadResponse { 
    public bool IsSuccessful { 
    get { ... } 
    set { ... } 
    } 
} 

[Serializable] 
public class UploadRequest { 
    public Allocation ReferenceAllocation { 
    get { ... } 
    set { ... } 
    } 
    // define other request properties 
    // ... 
} 

Wenn Sie definiert SOAP Bindings in Ihrer WSDL-Datei, UploadRequest Objekt aus der SOAP-Nachricht extrahiert und deserialisiert. Zu dem Zeitpunkt, zu dem das Steuerelement Ihre WebMethod-Implementierung erreicht, verfügen Sie über ein deserialisiertes UploadRequest Objekt in Arbeitsspeicher mit all seinen Eigenschaften festgelegt.

Um eine Methode wie folgt zu haben: öffentliche bool Upload (String xml) in einer [WebService] -Klasse und analysieren XML innerhalb der Methodenimplementierung ist definitiv etwas, von dem Sie wegdenken sollten.