Ist es möglich, Objekte von einem WebService zurückzugeben?

StackOverflow https://stackoverflow.com/questions/11879

  •  08-06-2019
  •  | 
  •  

Frage

Gibt es eine Möglichkeit, klassische Objekte zurückzugeben, anstatt eine gemeinsame Zeichenfolge zurückzugeben?Wenn nicht:Was sind die Best Practices?Transponieren Sie Ihr Objekt in XML und erstellen Sie das Objekt auf der anderen Seite neu?Welche anderen Möglichkeiten gibt es?

War es hilfreich?

Lösung

Wie bereits erwähnt, können Sie dies in .net über Serialisierung tun.Standardmäßig sind alle nativen Typen serialisierbar, sodass dies automatisch für Sie geschieht.

Wenn Sie jedoch über komplexe Typen verfügen, müssen Sie das Objekt mit dem Attribut [Serializable] markieren.Das Gleiche gilt für komplexe Typen als Eigenschaften.

Sie benötigen also zum Beispiel:

[Serializable]
public class MyClass
{
    public string MyString {get; set;}

    [Serializable]
    public MyOtherClass MyOtherClassProperty {get; set;}
}

Andere Tipps

Wenn das Objekt in XML serialisiert und in WSDL beschrieben werden kann, ist es ja möglich, Objekte von einem Webservice zurückzugeben.

Ja:In .NET nennt man dies Serialisierung, bei der Objekte in XML serialisiert und dann vom konsumierenden Dienst wieder in ihren ursprünglichen Objekttyp oder einen Ersatz mit derselben Datenstruktur rekonstruiert werden.

Wo möglich, transponiere ich die Objekte in XML – das bedeutet, dass der Webdienst portabler ist – ich kann dann in jeder Sprache auf den Dienst zugreifen, ich muss nur den Parser/Objekttransposer in dieser Sprache erstellen.

Da wir über WSDL-Dateien verfügen, die den Dienst beschreiben, erfolgt dies in einigen Systemen nahezu automatisiert.

(Zum Beispiel haben wir einen in reinem Python geschriebenen Server, der einen in C geschriebenen Server ersetzt, einen in C++/gSOAP geschriebenen Client und einen in Cocoa/Objective-C geschriebenen Client.Als Testframework verwenden wir SoapUI, das in Java geschrieben ist.

Es ist möglich, Objekte von einem Webdienst mithilfe von XML zurückzugeben.Aber Webdienste sollen plattform- und betriebssystemunabhängig sein.Durch die Serialisierung eines Objekts können Sie einfach ein Objekt speichern und aus einem Bytestrom, beispielsweise einer Datei, abrufen.Sie können beispielsweise ein Java-Objekt serialisieren, diesen Binärstrom konvertieren (vielleicht über eine Base-64-Kodierung in ein CDATA-Feld) und ihn an den Client des Dienstes übertragen.

Der Client könnte dieses Objekt jedoch nur wiederherstellen, wenn es Java-basiert wäre.Darüber hinaus ist eine tiefe Kopie erforderlich, um ein Objekt zu serialisieren und exakt wiederherzustellen.Tiefe Kopien können teuer sein.

Am besten erstellen Sie ein XML-Schema, das das Dokument darstellt, und erstellen eine Instanz dieses Schemas mit den Objektspezifikationen.

.NET führt dies automatisch mit Objekten durch, die serialisierbar sind.Ich bin mir ziemlich sicher, dass Java genauso funktioniert.

Hier ist ein Artikel, der sich mit der Objektserialisierung in .NET befasst:http://www.codeguru.com/Csharp/Csharp/cs_syntax/serialization/article.php/c7201

@Brian:Ich weiß nicht, wie die Dinge in Java funktionieren, aber in .net werden Objekte bis hinunter zu XML serialisiert, nicht zu Base64-Strings.Der Webservice veröffentlicht eine WSDL-Datei, die die für Ihren Webservice erforderlichen Methoden- und Objektdefinitionen enthält.

Ich würde hoffen, dass niemand Webservices erstellt, die einfach einen Base64-String erstellen

Daniel Auger:
Wie andere gesagt haben, ist es möglich.Wenn sowohl der Dienst als auch der Client ein Objekt verwenden, das auf beiden Seiten genau das gleiche Domänenverhalten hat, benötigten Sie wahrscheinlich überhaupt keinen Dienst.

lomax:Ich muss damit nicht zustimmen, da es ein etwas enger Kommentar ist.Wenn Sie einen Webservice verwenden, der Domänenobjekte mit XML serialisieren kann, können Kunden, die mit denselben Domain -Objekten arbeiten Umgekehrt, indem Sie anderen Kunden erlauben, keine Kenntnis Ihrer Domain -Objekte zu haben, aber dennoch über XML mit Ihrem Service zu interagieren.

@Lomax:Sie haben zwei Szenarien beschrieben. Szenario 1: Der Client rehydriert die XML-Nachricht wieder in genau dasselbe Domänenobjekt.Ich betrachte dies als „Rückgabe eines Objekts“.Meiner Erfahrung nach ist dies eine schlechte Wahl und ich werde dies weiter unten erläutern. Szenario 2: Der Client rehydriert die XML-Nachricht in etwas anderes als genau dasselbe Domänenobjekt:Ich stehe zu 100 % dahinter, betrachte dies jedoch nicht als Rückgabe eines Domänenobjekts.Es ist wirklich das Senden einer Nachricht oder eines DTO.

Lassen Sie mich nun erklären, warum die DTO-Objektserialisierung über einen Webdienst hinweg wahr/rein/nicht wahr ist normalerweise eine schlechte Idee.Eine Behauptung:Um dies überhaupt tun zu können, müssen Sie entweder Eigentümer sowohl des Clients als auch des Dienstes sein oder dem Client eine Bibliothek zur Verfügung stellen, damit er das Objekt wieder in seinen wahren Typ umwandeln kann.Das Problem:Dieses Domänenobjekt existiert nun als Typ in zwei halbverwandten Domänen und gehört zu diesen.Im Laufe der Zeit müssen in einem Bereich möglicherweise Verhaltensweisen hinzugefügt werden, die im anderen Bereich keinen Sinn ergeben, und dies führt zu Umweltverschmutzung und möglicherweise schmerzhaften Problemen.

Normalerweise verwende ich standardmäßig Szenario 2.Ich verwende Szenario 1 nur, wenn es einen zwingenden Grund dafür gibt.

Ich entschuldige mich dafür, dass ich mit meiner ersten Antwort so knapp war.Ich hoffe, dass dies meine Meinung einigermaßen klarstellt.Lomax, es scheint, als wären wir halb einer Meinung ;).

JSON ist eine ziemlich standardmäßige Möglichkeit, Objekte im Web weiterzugeben (als Teilmenge von Javascript).Viele Sprachen verfügen über eine Bibliothek, die JSON-Code in ein natives Objekt konvertiert – siehe zum Beispiel simplejson in Python.

Weitere Bibliotheken für die JSON-Verwendung finden Sie im JSON-Webseite

Wie andere gesagt haben, ist es möglich.Wenn jedoch sowohl der Dienst als auch der Client ein Objekt verwenden, das auf beiden Seiten genau das gleiche Domänenverhalten aufweist, benötigten Sie wahrscheinlich überhaupt keinen Dienst.

Wie andere gesagt haben, ist es möglich.Wenn sowohl der Dienst als auch der Client ein Objekt verwenden, das auf beiden Seiten genau das gleiche Domänenverhalten hat, benötigten Sie wahrscheinlich überhaupt keinen Dienst.

Ich muss dem widersprechen, da es sich um einen etwas engstirnigen Kommentar handelt.Die Verwendung eines Webservices, der Domänenobjekte in XML serialisieren kann, bedeutet, dass es für Clients einfacher ist, mit denselben Domänenobjekten zu arbeiten, aber es bedeutet auch, dass diese Clients auf die Verwendung des bestimmten Webservices beschränkt sind, den Sie bereitgestellt haben und in dem er auch funktioniert Dies können Sie umkehren, indem Sie anderen Clients ermöglichen, keine Kenntnis von Ihren Domänenobjekten zu haben, aber dennoch über XML mit Ihrem Dienst interagieren.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top