Ich möchte, dass einige Datenmitglieder einige Werte erhalten, wenn ich eine Instanz von DataContract auf dem Client erstelle. Dies geschieht nicht mithilfe von Konstruktoren. Ich habe verschiedene Foren durchsucht und festgestellt, dass wir die Attribute [OnDeserializing] und [OnDeserialized] verwenden müssen. Dies funktioniert auch nicht. Kann jemand hier etwas vorschlagen? Die andere Alternative besteht darin, Konstruktoren in den partiellen Klassen auf der Clientseite zu erstellen. Ich möchte das vermeiden.
Bitte finden Sie den folgenden Code:
Serverseitig: Datenvertrag
%Vor%Clientseite - Initialisierung
%Vor% Der Codegenerator, der zum Erstellen von WCF-Proxyklassen verwendet wird, erstellt kompatible Vertragstypen und verwendet nicht denselben Typ wie vom WCF-Dienst. Der einfachste Weg, um das zu erreichen, was Sie wollen, ist, den Konstruktor selbst auf Ihrem Client zu erstellen, da der erzeugte Code partial :
Wenn Sie dies nicht tun möchten, können Sie WCF dazu veranlassen, Typen wiederzuverwenden, auf die bereits von Ihrem Client-Projekt verwiesen wird. Wenn sich Ihre Datenvertragsklassen (wie empfohlen) in einer separaten Bibliothek befinden, können Sie auf diese Bibliothek verweisen und anschließend Ihr WCF-Clientprojekt neu konfigurieren, um die freigegebenen Typen aus der referenzierten Assembly wiederzuverwenden.
Die mit den Attributen DataMember zugewiesenen Eigenschaften definieren nur, was in der generierten WSDL / XSD enthalten sein wird. Der Client generiert basierend auf wsdl / xsd eigene -Klassen, die für die Kommunikation mit dem Service verwendet werden. Es verwendet nicht die selben -Klassen, die auf dem Server verwendet werden.
Deshalb wirst du nicht bekommen:
DataContract [DataMember] Eigenschaften / Felder (der Client generiert immer öffentliche Eigenschaften / Felder) DataContract Stellen Sie sich das Szenario vor, in dem sich ein Java-Client mit Ihrem Dienst verbinden möchte. Erwarten Sie, dass die Java-Klassen mit demselben Konstruktor generiert werden? Was ist mit den [OnDeserialized] Attributen? Was ist mit einem Java-Skript-Client oder Python-Client?
Wenn Sie anfangen, auf diese Weise darüber nachzudenken, beginnen Sie zu verstehen, warum Sie nicht haben können, was Sie wollen (zumindest nicht, ohne Bibliotheken zwischen dem Client und dem Server zu teilen).
Die Realität ist, dass Sie einen Client nicht zwingen können, Klassen zu haben, die immer Standardwerte haben und Sie können nicht immer gültige Daten zurücksenden, der Client kann immer nur eine Nachricht senden, die Müll enthält, wenn er will. Sie haben ein wenig Kontrolle über einige Aspekte der Nachricht mit dem IsRequired und 'EmitDefaultValue', die Checks in das xsd hinzufügen, um sicherzustellen, dass etwas in der Nachricht vorhanden ist, aber Sie müssen auf dem Server eine Validierung durchführen, Sie können gehe nicht davon aus, dass die Objekte, die du zurückbekommst, validiert werden.
Mein Vorschlag wäre, DTOs aus Ihren Domain-Objekten zu erstellen, um sie über die Leitung zu senden, die keine Überprüfung irgendeiner Art enthalten, sie sind nur einfache Taschen, um die Daten zu halten. Erstellen Sie anschließend Factorys, um Ihre Domänenobjekte in DTOs und DTOs in Clientobjekte umzuwandeln. Die Factory übernimmt einfach das DTO und übergibt die Member in den Konstruktor des Domänenobjekts. Dann kann Ihre Validierungslogik im Konstruktor des Domänenobjekts enthalten sein, zu dem sie gehört. Mit dem Ansatz, den Sie derzeit haben, werden Sie wahrscheinlich die Validierung leicht verdrehen, so dass es sowohl vom Konstruktor als auch von der [OnDeserialized] -Methode durchgeführt werden kann.
Tags und Links wcf datacontract