Какая-либо причина не использовать XmlSerializer?

XmlSerializer может избавить вас от многих проблем, если вы регулярно сериализуете и десериализуете одни и те же типы, и если вам нужно, чтобы сериализованные представления этих типов могли использоваться различными платформами (т.е. Java, Javascript и т.д.) Я рекомендую использовать XmlSerializer, когда это возможно, поскольку он может облегчить значительную часть хлопот, связанных с самостоятельным преобразованием графа объектов в XML.

Есть некоторые сценарии, в которых использование XmlSerializer не является лучшим подходом. Вот несколько случаев:

• Когда вам нужно быстро обработать большие объемы xml-данных.
  • Используйте вместо этого XmlReader
• Когда вам нужно выполнить повторяющийся поиск в xml-документе с помощью XPath
• Когда структура xml-документа достаточно произвольна и не соответствует известной объектной модели
• Когда XmlSerializer накладывает требования, которые не удовлетворяют вашим проектным требованиям:
  • Не используйте его, если у вас нет публичного конструктора по умолчанию
  • Вы не можете использовать атрибуты xml serializer для определения xml-вариантов имен элементов и атрибутов для соответствия необходимой схеме Xml

Да, я лично использую автоматическую сериализацию XML - хотя вместо этого я использую DataContractSerializer, изначально введенный из-за WCF (возможность сериализации типов вообще без атрибутов очень полезна), поскольку он не встраивает типы там. Конечно, поэтому вам необходимо знать тип объекта, который вы десериализуете при обратной загрузке.

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

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

В общем, я считаю, что путь DCS - самый быстрый и безболезненный путь.

В качестве альтернативы вы также можете исследовать использование Linq to XML для чтения и записи XML, если вам нужен полный контроль - но вам все равно придется обрабатывать типы по каждому члену с этим.

Я смотрел на это недавно (избегая этого как чумы, потому что я не видел смысла) после того, как прочитал об этом в раннем доступе к новой книге Джона Скита.Должен сказать - меня больше всего впечатлило, насколько легко работать с XML.

Ну, это не дает вам столько контроля над выводом, очевидно. Лично я считаю, что LINQ to XML позволяет достаточно легко написать это вручную, поэтому я с удовольствием делаю это таким образом, по крайней мере, для достаточно небольших проектов. Если вы используете .NET 3.5 или 4, но не используете LINQ to XML, сразу же обратите на него внимание - он гораздо гораздо приятнее, чем старый DOM.

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

EDIT: Я не думаю, что XML-сериализация поддерживает построение действительно неизменяемых типов, в то время как это, очевидно, осуществимо при ручном построении. Поскольку я являюсь поклонником неизменяемости, это определенно то, о чем я бы беспокоился. Если вы реализуете IXmlSerializable, я полагаю, вы можете обойтись public неизменяемостью, но вы все равно должны быть частно изменяемыми. Конечно, я могу ошибаться - но это стоит проверить.

Я считаю, что основными недостатками XmlSerializer являются:

1) Для сложных графов объектов, включающих коллекции, иногда трудно получить именно ту схему XML, которую вы хотите, используя атрибуты управления сериализацией.

2) Если вы измените определения классов между одной версией приложения и следующей, ваши файлы станут нечитаемыми.

Я много использовал XmlSerializer в прошлое и, вероятно, продолжит его использовать.Однако самая большая ошибка - это уже упомянутая выше:

Ограничения на сериализатор (например, ограничение на общедоступные члены) либо 1) накладывают конструктивные ограничения на класс, не имеющие ничего общего с его основной функцией, либо 2) заставляют усложнение работы с этими ограничениями.

Конечно, другие методы сериализации Xml также увеличивают сложность.

Думаю, мой ответ таков: не существует правильного или неправильного ответа, подходящего для всех ситуаций; выбор метода сериализации - это лишь одно из многих соображений дизайна.

Когда вы хотите передать много данных и у вас очень ограниченные ресурсы.

Вот несколько сценариев.

• Вам приходится иметь дело с большим количеством XML-данных - сериализатор может перегрузить вашу память. Однажды у меня такое случилось с простой схемой, которая содержала дамп базы данных для 2000 или около того таблиц. Всего несколько классов, но в итоге сериализация не сработала - пришлось использовать потоковый парсер SAX.

Кроме этого - в обычных условиях я ничего не вижу. Гораздо проще работать с XML Serializer, чем использовать парсер нижнего уровня, особенно для более сложных данных.