DataContract vs. XmlType

Question

Как часть попытки изучить WCF, я читаю о сериализации. Я пытаюсь понять, как я могу контролировать сериализацию в .NET 3.5. Например, у меня есть простой класс с несколькими общедоступными свойствами. Добавив атрибут DataContract к этому классу, я могу, например, управлять пространством имен и именем класса по мере его сериализации.

С другой стороны, я мог бы добавить атрибут Serializable (возможно, даже не обязательно) и атрибут XmlType, который также позволяет мне контролировать пространство имен и имя, которое используется для сериализации класса.

Я реализовал оба подхода и использую класс в ServiceContract как часть вызова интерфейса. Затем я использую Http-анализатор, чтобы увидеть, как различные объекты сериализуются, и я заметил, что XmlType вообще не влиял на xml в http.

Я пытался понять это весь день. Чего мне не хватает?

Обновление: Я понимаю разницу между ними и почему они там. Я просто не понимаю, почему я не могу повлиять на сгенерированный XML с помощью XmlType или (только что попробовал XmlRoot).

По сути, вы можете управлять всеми деталями сериализации, реализуя IXmlSerializable, за исключением пространств имен и имени элемента верхнего уровня. Для этого я предполагал, что вам понадобится атрибут XmlType или XmlRoot. Был ли я не прав?

Answer 1

Основной смысл DataContractSerializer заключается в том, чтобы не контролировал детали сериализации. Вместо этого идея состоит в том, чтобы сериализовать ваши данные в форму, которая может использоваться наибольшим числом клиентов.

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

Сериализатор XML следует использовать только в тех случаях, когда вам абсолютно необходим контроль над сериализацией или десериализацией деталей XML. Если вам не нужно много контроля, придерживайтесь Сериализатора Контракта Данных.

Answer 2

Точка уточнения: Атрибут [Serializable] не имеет ничего общего с XmlSerialization. Атрибут [Serializable] имеет отношение к Runtime.Serialization. Смущает, да.

В .NET слишком много сериализаторов.

Answer 3

См. XmlSerializer против DataContractSerializer: сериализация в Wcf .

Редактировать

См. Настройте сериализацию XML вашего объекта .NET с помощью атрибутов XML .NET . Получите ваши данные для сериализации в форму, которую вы хотите в первую очередь. Затем поместите атрибут XmlSerializerFormat.

[ServiceContract]
[XmlSerializerFormat]
public interface MyService
{
    [OperationContract]
    [XmlSerializerFormat]
    void MyMethod();
}

Answer 4

Что ж, существует множество сравнений DataContractSerializer и XmlSerializer.

Я думаю, что основные моменты, на мой взгляд:

• DataContract "opt-in" - вам нужно явно добавить атрибут [DataMember] к любому полю или свойству (общедоступному, частному, внутреннему или какому-либо другому) для сериализации - если у вас его нет, он выиграл не быть там. XmlSerializer просто сериализует все общедоступные свойства

• DataContract позволяет вам указать определенный порядок элементов данных - XmlSerializer просто использует порядок, в котором они появляются в вашем исходном коде

• Для вашего класса XmlSerializer требуется открытый конструктор без параметров

В простых примерах эти преимущества DataContractSerializer могут показаться не слишком большими, но на самом деле это может быть явным преимуществом в крупномасштабных приложениях, если ваш объект данных не должен иметь открытый параметр. меньше конструктора, и вам не нужно «искусственно» создавать элементы поверхности в качестве открытых свойств, чтобы просто включить их в сериализацию.

Марк