WCF DataContract / ServiceOperation с использованием типа .NET XmlDocument - PullRequest
3 голосов
/ 21 ноября 2008

Мне просто интересно узнать о контрактах на передачу данных, передаваемых по проводам в WCF. я знаю, что для обеспечения функциональной совместимости нежелательно (может быть, даже не разрешено?) отправлять собственные типы .NET в рамках контракта на данные.

Я хочу иметь службу, которая принимает в качестве входа ServiceOperation тип .NET XmlDocument. Если бы я создал класс-оболочку (который был бы помечен атрибутом DataContract), который содержит тип XmlDocument (который был бы помечен атрибутом DataMember), и использовал бы его в качестве параметра для ServiceOperation - это будет законно / возможно?

Как я могу обеспечить совместимость, сохраняя при этом удобство типа XmlDocument? Может ли быть лучшим выбором при принятии string в качестве параметра для ServiceOperation, а затем создать экземпляр XmlDocument с использованием метода XmlDocument.LoadXml(string) на стороне службы?

приветствует любую помощь / просмотры / комментарии, я только начинаю разбираться с wcf, так что я просто хочу прояснить любую путаницу в моей голове, прежде чем погрузиться в создание службы.

СПАСИБО!

Ответы [ 5 ]

2 голосов
/ 18 декабря 2008

Вам нужно будет добавить атрибут [XmlSerializerFormat].

Итак (без использования Datacontract, хотя вы можете использовать это тоже):

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

[XmlSerializerFormat]

открытый интерфейс IBlah

{

[OperationContract]

XmlDocument Returnxmldoc ();

}

1 голос
/ 21 ноября 2008

Чаще всего разработчики кодируют вещи для «интероперабельности», когда у них действительно нет причин / необходимости вообще делать это.

Вполне нормально использовать нативные типы .NET. Пример: Вы бы разбили «Точка» на два целых числа для сериализации?

К сожалению, System.Xml.XmlDocument ... не сериализуем:)

Вы можете использовать "XElement", хотя ... он отлично работает (в пространстве имен System.Xml.Linq).

0 голосов
/ 24 ноября 2008

У вас есть XSD для вашего XML-документа? В этом случае довольно просто сгенерировать составную структуру DataContract с помощью svcutil.exe (svcutil.exe / dconly schemaName.xsd). На этом этапе вы можете использовать DataContractSerializer для перемещения между вашим XML-документом и Composite of DataContracts, которые можно использовать в интерфейсе вашего сервиса и в ваших реализациях, если вы захотите это сделать.

Кроме того, я согласен с предыдущими постерами с комментариями YAGNI о совместимости.

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

0 голосов
/ 23 ноября 2008

Что бы я сделал в вашем втором случае, это создать контракт данных в отдельной dll и ссылаться на него в обоих приложениях (я предполагаю, что у вас есть контроль над обоими Сервисами). Поэтому, когда вы создаете свой прокси-класс для Сервиса A в Сервисе B, вы можете сказать, что ваши контракты данных относятся к известному типу и указывают на dll контрактов данных. Кстати, VS 2008 делает это по умолчанию. Если вы используете .NET 3.0, вам может потребоваться создать классы вручную с помощью svcutil.

Надеюсь, это поможет.

Ура, Вагнер.

0 голосов
/ 21 ноября 2008

Передача строки будет лучше для взаимодействия, но если вы хотите передать типы данных CLR, вы можете посмотреть на разметку ваших классов с помощью атрибута KnownType.

...