XML HTTP POST-Integration in .NET

Question

Ich arbeite an einem .NET-Projekt, das mit einem externen Unternehmen integriert ist. Diese Firma sendet uns XML-Nachrichten über HTTP POST (Roh-XML, nicht SOAP). Es gibt grundsätzlich drei verschiedene Arten von XML-Nachrichten, die sie uns senden, die alle ihre eigenen XSDs haben. Es gibt keine Vererbungshierarchie zwischen diesen XSDs, sie sind alle im Grunde eigenständige XML-Entitäten.

Im Moment verwenden wir nur eine IHttpHandler .ashx-Klasse, um das XML zu verarbeiten. Wir haben aus jeder XSD eine Klasse erstellt und verwenden XmlSerializer, um die verschiedenen XML-Nachrichten in Objekte zu konvertieren. Dies ist nicht ideal, da wir den Nachrichtentyp kennen müssen, bevor Sie den entsprechenden XmlSerializer zur Verarbeitung erstellen. Wir schauen uns gerade den Namen des Root-Elements in der Nachricht an, um zu entscheiden, welcher Typ an den XmlSerializer übergeben werden soll.

Es muss einen besseren Weg geben, dies zu tun ... Gibt es etwas in WCF, das dies automatisch mit einfachem XML tun kann? Oder ist ein XML-Serializer verfügbar, der mehrere Typen dynamisch serialisieren kann? Irgendwelche anderen Vorschläge?

Answer 1

WCF als RESTful + POX

REST and POX
REST in Windows Communication Foundation (WCF)

Answer 2

Warum nicht in ein Dataset mit XmlReadMode.Auto lesen? Dann haben Sie ein Objekt, das entsprechend gelesen werden kann - Sie können Tabelle [0] ansehen, um zu sehen, welche Sie haben.

Answer 3

Das einzige Problem, das ich mit XMLSerializer ist, dass es ziemlich spröde ist. Ändern Sie den XML-Code für weitere Funktionen, und Sie könnten Clients beschädigen. Ich denke, es ist besser, das XML selbst zu analysieren. Vielleicht mit Linq XDocument/XElement?

Answer 4

Die Linq to XML-Klassen sind sehr flexibel und einfach zu bedienen. Sie können ein XElement einfach neu erstellen und Ihre XML-Zeichenfolge einwerfen.

XElement xml = XElement.Parse(receivedXmlString); 

Arbeit erledigt.

Anders Heijlsberg präsentierte eine gute Sitzung dazu auf MIX07, "Using LINQ to Dramatically Improve Data Driven Development in Web Applications". Sie könnten das Video nützlich finden. Die Linq zu XML Zeug ist etwa 26 Minuten in.

Answer 5

Ich würde den XML-Serializer verwenden, nur auf eine allgemeinere Weise als Sie gerade tun.

Wenn es sich bei der Nachricht um einen von drei Typen handelt, können Sie den XML-Serializer weiterhin zum automatischen Lesen und Deserialisieren verwenden. Sie müssen das erste Element nicht überprüfen, um zwischen ihnen zu unterscheiden. Sie müssen die XSDs jedoch zu einer einzigen konsolidierten XSD zusammenführen und dann einen einzelnen konsolidierten "Union" -Typ auf der .NET-Seite erstellen. Sie können dies auch tun, indem Sie die generierten Typen zusammenführen und dann eine generierte XSD daraus mit dem Tool xsd.exe ableiten.

Die angebliche "Sprödigkeit" des XML-Serialisierers ist meines Erachtens kein Thema. XML im Allgemeinen kann spröde sein, wenn Sie eine XML-Datenbindungstechnologie verwenden, die von XSD abhängt, wie auch die XML-Serialisierung. Es ist nicht XML-Serialisierung per se, das ist spröde. IT ist das Schema, das brüchig sein kann. Schema-basierte Ansätze - einschließlich der XML-Serialisierung in .NET - können brüchig sein, wenn das Schema selbst nicht im Hinblick auf die Evolution entworfen wurde. ZB die angemessene Verwendung von xsd: any und xsd: xmlAny, Nachrichtenversions-Tags usw. Die gute Nachricht ist, dass es eine gute Anleitung zum Entwerfen eines flexiblen Schemas gibt, das sich elegant entwickeln kann.

Dies ist jedoch möglicherweise kein Problem, da das Schema bereits vorhanden ist. In jedem Fall werden Sie dem System keine "Brüchigkeit" hinzufügen, indem Sie den XML-Serializer verwenden.