WCF DataContract/ServiceOperation impliquant .NET XmlDocument type

Question

Je m'interroge simplement sur les contrats de données à envoyer sur le réseau dans la communication WCF. Je sais que pour des raisons d'interopérabilité, il n'est pas conseillé (peut-être même pas autorisé?) d'envoyer des types .NET natifs dans le cadre d'un contrat de données.

Je souhaite avoir un service qui accepte, en entrée d'un ServiceOperation, un type .NET XmlDocument. Si je devais créer une classe wrapper (qui serait marquée avec DataContract attribut) qui détient un type XmlDocument (qui serait marqué avec l'attribut DataMember), et l'utiliser comme paramètre pour le ServiceOperation - serait-ce légal/possible?

Comment puis-je assurer l'interopérabilité, tout en conservant la commodité du type XmlDocument? Serait-il préférable de choisir un string comme paramètre pour le ServiceOperation, puis d'instancier un XmlDocument en utilisant la méthode XmlDocument.LoadXml(string) du côté service?

Bravo pour toute aide/vues/commentaires, je commence à peine à maîtriser wcf, donc je veux juste éclaircir toute confusion dans ma tête avant de plonger tête première dans la création d'un service.

MERCI!

Answer 1

Passez une chaîne serait mieux pour interop, mais si vous voulez passer des types de données CLR vous pouvez chercher à marquer vos classes avec l'attribut KnownType.

Answer 2

Plus souvent qu'autrement, les développeurs codent des choses pour des raisons d'interopérabilité, quand ils n'ont vraiment aucune raison de le faire.

Il est parfaitement acceptable d'utiliser des types .NET natifs. Exemple: Voulez-vous décomposer "Point" en deux entiers pour la sérialisation?

Malheureusement, cependant, le System.Xml.XmlDocument ... n'est pas sérialisable :)

Vous pouvez utiliser "XElement" ... mais qui fonctionne parfaitement (dans l'espace de noms System.Xml.Linq).

Answer 3

Ce que je ferais dans votre deuxième cas, est de créer un contrat de données dans une DLL séparée, et de le référencer sur les deux applications (je suppose que vous avez le contrôle sur les deux services). Ainsi, lorsque vous créez votre classe proxy pour le service A dans le service B, vous pouvez dire que vos contrats de données proviennent d'un type connu et pointent pour les contrats de données dll. BTW VS 2008 le fait par défaut. Si vous utilisez .NET 3.0, vous devrez peut-être créer les classes manuellement à l'aide de svcutil.

J'espère que cela aide.

Cheers, Wagner.

Answer 4

Avez-vous un XSD pour votre document XML? Si c'est le cas, il est assez facile de générer une structure composite DataContract à l'aide de svcutil.exe (svcutil.exe/dconly schemaName.xsd). À ce stade, vous avez le choix d'utiliser le DataContractSerializer pour vous déplacer entre votre document XML et un composite de DataContracts qui peut être utilisé dans votre interface de service et vos implémentations si vous le souhaitez.

Aussi, je suis d'accord avec le (s) poster (s) précédent (s) avec le commentaire YAGNI sur la compatibilité.

JB http://jb-brown.blogspot.com

Answer 5

Vous devez ajouter l'attribut [XmlSerializerFormat].

donc (sans utiliser DataContract bien que vous pouvez l'utiliser aussi):

[ServiceContract (namespace = "urn: SerializationTest")]

[XmlSerializerFormat]

interface publique IBlah

{

[OperationContract]

XmlDocument Returnxmldoc();

}