Вопрос

Текущая реализация

База данных Sql Server 2005 с таблицей под названием messages со столбцом под названием MessageXml типа xml.

Проект библиотеки C # с классом Linq to Sql, который генерирует класс с именем Message с полем MessageXml типа XElement.

Веб-сервис WCF, который предоставляет класс MessagePayload со свойством MessageXml типа XElement.

Веб-сервис не обслуживает мой класс Message, созданный Linq to Sql.Я использую легкий предмет в качестве промежуточного звена.

Вопрос

Действительно ли XElement тот тип, который я хочу использовать в своей службе WCF, или есть лучший тип?XML, который предназначен для передачи в службу, должен быть полным документом doc.Кроме того, у меня возникли небольшие проблемы с загрузкой xml-документов в качестве XElement.Я думаю, что я должен предоставить полный тип документа xml в легковесном классе для сервиса, но я немного запутался в различиях между XDocument и XmlDocument.

Кроме того, я не могу предоставить класс WCF Message со свойством типа XDocument, потому что он содержит свойство типа XDeclaration, которое не может быть сериализовано.

Если я использую XmlDocument, мне приходится выполнять это странное преобразование типов xml в моем переводе между классом Linq и облегченным классом.

 XmlDocument doc = new XmlDocument();
 doc.LoadXml(message.MessageXml.ToString());

 MessageEnvelope retVal = new MessageEnvelope()
 {
      MessageXml = doc,
 };

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

Это было полезно?

Решение

Вы можете использовать либо XElement, либо XmlElement:

public XmlElement GetXmlElement()
{
    var doc = new XmlDocument();
    doc.Load(PREFIX + @"Enumerations.wsdl");

    return doc.DocumentElement;
}

public XElement GetXElement()
{
    var doc = XDocument.Load(PREFIX + @"Enumerations.wsdl");
    return doc.Root;
}

Вы не хотите ни того, ни другого XDocument ни XmlDocument.Помните, что все, что вы вернете, будет находиться в середине XML-документа, содержащего конверт SOAP.У вас не может быть документа внутри документа, поэтому вам нужен элемент.

Другие советы

Джон Сондерс здесь при деньгах.Чтобы немного уточнить, если вы посмотрите на WSDL, который генерируется, когда вы возвращаете либо XmlElement или XElement, вы увидите что-то вроде этого:

<xs:complexType>
  <xs:sequence>
    <xs:any minOccurs="0" processContents="lax"/>
  </xs:sequence>
</xs:complexType>

Вот и все.По сути, это означает, что сюда может попасть любой XML-файл.Это также означает, что, вопреки предложению Чансика, он не привязывает возвращаемый тип к конкретному типу .NET.

Так что да, вам не нужно использовать строку.

Используйте любой тип, который вам нужен для сериализации класса (String всегда хорошо работал для меня), а затем выполняйте преобразования, когда это необходимо, на стороне сервера или клиента, чтобы сохранить целостность документа.Вы также можете создать XDocument из одного или нескольких XElements, поэтому я бы выбрал XElement.

В худшем случае вы даже можете переопределить поведение сериализации вашего класса (не слишком ужасно, если вы хорошо разбираетесь в рефлексии).

XmlDocument - это старый документ, не связанный с Linq.Это одна и та же концепция, реализованная в разных классах.

В целом, XDocument и XElememnt предпочтительнее, чем XmlDocument и XmlElement с точки зрения производительности.

Тем не менее, я бы предложил использовать string отправить XML-документ через службу WCF невозможно по следующим причинам:

  1. Функциональная совместимость
    • Клиенты не привязаны к конкретному.Версия NET Framework (клиент может выбрать использование XDocument или XmlDocument.Даже клиенты на базе Java могут поддерживаться до тех пор, пока службы WCF настроены таким образом).
  2. Правильная обработка XML-объявления, если оно содержится в исходном XML-документе.

Примечание:Пожалуйста, не забудьте соответствующим образом настроить конфигурацию для поддержки большого xml-документа.Например, basicHttpBindingмаксимальный размер сообщения по умолчанию составляет 64 КБ.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top