2016-04-20 2 views
0
auf den korrekten Wert eingestellt

Wenn ich einen WCF-Dienst, der eine Methode enthält, die so aussieht ...Warum haben seine Parameter der WCF-Service-Methode nicht

[OperationContract] 
    public void Jim(int ID) { 
    // DO SOMETHING HERE 
    } 

... und ich diese verwenden Methode in einem Client, alles funktioniert gut.

Wenn ich den Parameter der Servicemethode nachträglich in id umbenenne, dann wird der Parameter beim Aufruf der Servicemethode nicht gesetzt und hat den Wert Null.

Wenn ich dann die Service-Referenz im Client neu generieren, wird der Parameter korrekt festgelegt.

Was ich nicht verstehe ist, warum dies teilweise funktioniert. Ich hätte erwartet, dass es vollständig funktioniert (dh den Parameter auf den richtigen Wert gesetzt hat) oder mit einer Ausnahme fehlschlägt.

Wenn die eingehende Anforderung als die gleiche Methode erkannt wurde, sollte sie den Parameternamen erkannt und den Wert festgelegt haben. Wenn es nicht mit den Parameternamen übereinstimmt, sollte es als eine andere Methode angesehen worden sein und eine Ausnahme ausgelöst haben, dass die gewünschte Methode fehlte. Ich verstehe nicht, warum es die richtige Methode aufgerufen hat, aber nicht den Parameterwert.

Kann mir jemand das erklären?

Antwort

1

In einem SOAP-Dienst wird der Parametername tatsächlich in der für die Operation generierten XSD enthalten sein. Dies bedeutet, dass die Definition der Operation immer noch den alten Parameternamen enthält, wenn Sie die Service-Referenz des Clients nicht aktualisieren. Wenn WCF den Wert über die Verbindung vom Client zum Server serialisiert, wird der Parameterwert vom Client aufgrund der Namenskonflikt nicht ordnungsgemäß serialisiert.

Betrachten Sie es auf diese Weise:

Der Client, basierend auf seinen Service Referenzpakete auf den Betrieb und die Parameter in ein XML-Dokument, das dann wiederum sendet als Anforderung an den Server auf. Das ist Serialisierung.

Der Server muss nun basierend auf seiner Servicereferenz den XML-Code für die Anforderung entpacken und herausfinden, was zu tun ist. Sie entpackt die Operation und vergleicht sie mit ihrer Liste bekannter Operationen in ihrer Dienstreferenz; Sie sehen, dass Sie eine Operation mit dem Namen Jim anfordern, die einen String-Parameter benötigt. Anschließend werden alle/alle Parameterwerte für diese Operation im XML-Dokument auf alle übergebenen Werte überprüft. Dies ist eine Deserialisierung. In Ihrem Fall hat der Client den Parameter mit einem anderen Namen als dem Wert übergeben, den der Dienst erwartet. Es wird nicht in der Lage sein, den Wert in der XML zu finden, und wird den Wert nicht festlegen.

Damit die Dinge ordnungsgemäß funktionieren, müssen der Client und der Dienst der Service-Referenzdefinition zustimmen und übereinstimmen.

This beschreibt WCF Data Contracts und die Serialisierung und ist es wert, gelesen zu werden.

+0

@codechum Danke, aber basierend darauf (was ich eigentlich erwartet hätte), hätte ich gedacht, dass die Methode mit dem Parameter namens id als eine andere Methode als die mit angesehen wurde der Parameter namens ID bedeutet, dass ich eine fehlende Methodenausnahme erhalten hätte. Ich verstehe nicht, wie es mit der Methode übereinstimmt, aber nicht mit dem Parameter übereinstimmt. –

+1

@AvrohomYisroel erhalten Sie keine fehlende Methodenausnahme. Die Parameterwerte der Methode sind nur ein Teil der Nachricht. Ihre Clientdefinition der Methode besagt, dass der Parametername "id" ist; Ihr Server sagt, dass der Parametername "ID" ist.Wenn der Client die 'Jim'-Operation des Servers aufruft, wird er die' id = 1 'übergeben; Wenn der Server jedoch die Nachricht betrachtet, sucht er explizit nach ID = . Beachten Sie die Falldifferenz. – codechurn

+0

@codechum Danke für die Erklärung. Sieht immer noch etwas komisch aus, aber ich denke, ich verstehe, warum es so funktioniert. Ich hätte gedacht, sie hätten es anders gemacht, aber sie haben mich nicht gefragt! Wenigstens weiß ich, was jetzt passiert ist. –

Verwandte Themen