Я только что узнал о классе XmlSerializer в .Net. Прежде, чем я всегда разбирался и писал свой XML, используя стандартные классы. Прежде чем погрузиться в это, мне интересно, есть ли случаи, когда это не правильный вариант.
EDIT: стандартными классами я имею в виду XmlDocument, XmlElement, XmlAttribute... и т.д.
Существует множество ограничений при использовании XmlSerializer:
Эти ограничения часто заставляют вас принимать определенные дизайнерские решения, которые вы не делали бы в других ситуациях... и инструмент, который заставляет вас принимать плохие дизайнерские решения, обычно не очень хорош;)
Это, как говорится, может быть очень удобно, когда вам нужен быстрый способ хранения простых объектов в формате XML. Мне также нравится тот факт, что у вас довольно хороший контроль над сгенерированной схемой.
Ну, это не дает вам достаточно большого контроля над выходом, очевидно. Лично я считаю, что LINQ to XML позволяет достаточно легко написать это вручную, что я счастлив сделать это таким образом, по крайней мере, для достаточно небольших проектов. Если вы используете .NET 3.5 или 4, но не используете LINQ to XML, изучите его сразу - это намного лучше, чем старый DOM.
Иногда приятно иметь возможность контролировать сериализацию и десериализацию... особенно при изменении макета ваших данных. Если вы не в такой ситуации и не ожидаете, что будете в ней, то встроенная сериализация XML, вероятно, будет прекрасной.
EDIT: Я не думаю, что XML-сериализация поддерживает построение действительно неизменяемых типов, тогда как это, очевидно, возможно из ручной работы. Поскольку я поклонник неизменности, это определенно то, о чем я буду беспокоиться. Если вы реализуете IXmlSerializable, я считаю, что вы можете сделать это с публичной неизменностью, но вы все равно должны быть конфиденциально изменены. Конечно, я могу ошибаться, но стоит проверить.
XmlSerializer может сэкономить вам много хлопот, если вы регулярно сериализуете и десериализируете одни и те же типы, и если вам нужны сериализованные представления тех типов, которые будут потребляться различными платформами (например, Java, Javascript и т.д.), я делаю рекомендуйте использовать XmlSerializer, когда сможете, поскольку он может облегчить значительное количество проблем, пытаясь управлять преобразованием из графа объектов в XML самостоятельно.
Существуют некоторые сценарии, в которых использование XmlSerializer не является лучшим подходом. Вот несколько примеров:
Я считаю, что основными недостатками XmlSerializer являются:
1) Для сложных графиков объектов, связанных с коллекциями, иногда трудно получить именно схему XML, которую вы хотите, используя атрибуты управления сериализацией.
2) Если вы измените определения классов между одной версией приложения и следующей, ваши файлы станут нечитаемыми.
Да, я лично использую автоматическую сериализацию XML - хотя я использую DataContractSerializer, первоначально введенный из-за WCF, вместо этого (возможность сериализации типов без атрибутов вообще очень полезна), поскольку там не встроены типы. Конечно, вам необходимо знать тип объекта, который вы десериализируете при загрузке обратно.
Большая проблема заключается в том, что сложно сериализовать и для атрибутов, не применяя IXmlSerializable для типа, данные которого вы, возможно, захотите записать, или выставляете некоторые другие типы, которые сериализатор может обрабатывать изначально.
Я думаю, что самая большая проблема заключается в том, что вы не можете сериализовать интерфейсы автоматически, потому что DCS хочет иметь возможность создавать экземпляры снова, когда он получает XML обратно. Стандартные интерфейсы сбора данных, однако, поддерживаются изначально.
В общем, я нашел, что маршрут DCS был самым быстрым и безболезненным.
В качестве альтернативы вы также можете исследовать использование Linq для XML, чтобы читать и писать XML, если вам нужен полный контроль, - но вам все равно придется обрабатывать типы на члене по элементам с помощью этого.
Я смотрел на это недавно (избегая его, как чумы, потому что я не мог понять смысла), прочитав об этом раннем доступе к новой книге Джона Скита. Должен сказать - меня больше всего впечатлило то, как легко он работает с XML.
Я использовал XmlSerializer много в прошлом и, вероятно, продолжу его использовать. Однако самая большая ошибка - это уже упомянутое выше:
Ограничения на сериализатор (например, ограничение на публичные элементы) либо 1) налагают конструктивные ограничения на класс, который не имеет ничего общего с его основной функцией, либо 2) заставляют увеличивать сложность при работе с этими ограничениями.
Конечно, другие методы сериализации Xml также увеличивают сложность.
Итак, я думаю, мой ответ заключается в том, что нет правильного или неправильного ответа, который бы соответствовал всем ситуациям; использование метода сериализации является лишь одним соображением по дизайну среди многих других.
Повторите несколько сценариев.
Кроме того - я не вижу никаких при нормальных обстоятельствах. Это гораздо более простой способ справиться с XML-сериализатором, чем использовать парсер более низкого уровня, особенно для более сложных данных.
Когда вы хотите передать много данных, и у вас очень ограниченные ресурсы.