Я только что узнал о классе XmlSerializer в .Net. Прежде, чем я всегда разбирался и писал свой XML, используя стандартные классы. Прежде чем я погружусь в это, мне интересно, есть ли случаи, когда это не правильный вариант.Любые причины не использовать XmlSerializer?
EDIT: Стандартными классами я имею в виду XmlDocument, XmlElement, XmlAttribute ... и т. Д.
Есть много ограничений, когда вы используете XmlSerializer:
Эти ограничения часто заставляют вас принимать определенные дизайнерские решения, которые не были сделаны вами в других ситуациях ... и инструмент, который заставляет вас принимать плохие дизайнерские решения, обычно не очень хорош;)
Это, как говорится, может быть очень удобно, когда вам нужен быстрый способ хранения простых объектов в формате XML. Мне также нравится тот факт, что у вас довольно хороший контроль над сгенерированной схемой.
Обратите внимание, что конструктор без параметров не должен быть общедоступным. частные и внутренние будут работать. – idlewire
@idlewire, вы правы, я никогда этого не осознавал. Однако я подозреваю, что он будет работать только при полном доверии ... –
Я считаю, что основные недостатки XmlSerializer являются:
1) Для сложных графов объектов, связанных с коллекциями, иногда трудно получить именно XML схему, которую вы хотите, используя атрибуты управления сериализации.
2) Если вы измените определения классов между одной версией приложения и следующей, ваши файлы станут нечитаемыми.
# 2 большой, которого я нахожу, многие программисты боятся –
@ neil-n: Определенно! – Mau
Это все еще не так хрупко, как 'BinarySerializer' –
Ну, это не дает вам достаточно большого контроля над выходом, очевидно. Лично я считаю, что LINQ to XML позволяет достаточно легко написать это вручную, что я счастлив сделать это таким образом, по крайней мере, для достаточно небольших проектов. Если вы используете .NET 3.5 или 4, но не используете LINQ to XML, изучите его сразу - это очень много, но много приятнее, чем старый DOM.
Иногда приятно иметь возможность контролировать сериализацию и десериализацию ... особенно при изменении компоновки ваших данных. Если вы не в такой ситуации и не ожидаете, что будете в нем, то встроенная сериализация XML, вероятно, будет прекрасной.
EDIT: Я не думаю XML-сериализация поддерживает построение действительно неизменяемых типов, тогда как это, очевидно, возможно из ручной работы. Поскольку я поклонник неизменности, это определенно то, о чем я буду беспокоиться. Если вы реализуете IXmlSerializable, я считаю, что вы можете делать с общественностью неизменяемости, но вы все равно должны быть конфиденциально изменены. Конечно, я мог ошибаться, но это стоит проверить.
не могли бы вы немного разъяснить, что вы имеете в виду, говоря, что вы поклонник неизменности? Какова ваша общая стратегия, связанная с сериализацией XML? –
@Dmitry: Я считаю, что когда мои типы неизменяемы, код проще рассуждать, а многопоточность проще. Для сериализации XML я часто в конечном итоге записываю свой собственный код ToXElement и FromXElement вручную. Это редко бывает сложно, и вы получаете полный контроль над тем, что генерируется. –
Тера в некоторых сценариев.
Кроме того - в обычных условиях я не вижу никаких признаков. Это гораздо более простой способ справиться с XML-сериализатором, чем использовать парсер более низкого уровня, особенно для более сложных данных.
XmlSerializer может сэкономить вам много проблем, если вы регулярно сериализуете и десериализируете одни и те же типы, и если вам нужны сериализованные представления тех типов, которые могут использоваться на разных платформах (например, Java, Javascript и т. Д.) I рекомендуйте использовать XmlSerializer, когда можете, поскольку это может облегчить значительное количество проблем, пытающихся управлять преобразованием из графа объектов в XML самостоятельно.
Есть несколько сценариев, в которых использование XmlSerializer не является лучшим подходом. Вот несколько случаев:
+1 для обозначения аргумента размера и XmlReader в качестве альтернативы – Abel
Когда Вы хотите передать много данных и у вас есть очень ограниченные ресурсы.
Да, я лично использую автоматическую сериализацию XML - хотя я использую DataContractSerializer, первоначально введенный из-за WCF, вместо этого (возможность сериализации типов без атрибутов вообще очень полезна), поскольку там не встроены типы. Конечно, вам необходимо знать тип объекта, который вы десериализуете при загрузке обратно.
Большая проблема с этим сложно сериализовать и для атрибутов, не применяя IXmlSerializable для типа, данные которого вы можете захотеть быть написаны так или подвергать другим типам, которые сериализатор может обрабатывать изначально.
Я думаю, что самая большая проблема заключается в том, что вы не можете сериализовать интерфейсы автоматически, потому что DCS хочет иметь возможность создавать экземпляры снова, когда он получает XML обратно. Стандартные интерфейсы сбора данных, однако, поддерживаются изначально.
В целом, однако, я нашел маршрут DCS самым быстрым и безболезненным.
В качестве альтернативы вы также можете исследовать использование Linq для XML для чтения и записи XML, если вам нужен полный контроль, но вам все равно придется обрабатывать типы на члене по элементам с этим.
Я смотрел на это недавно (избегая его, как чуму, потому что я не мог понять смысла), прочитав об этом раннем доступе к новой книге Джона Скита. Должен сказать - меня больше всего впечатлило то, как легко он работает с XML.
Я использовал XmlSerializer много в прошлом и, вероятно, продолжу его использовать. Однако наибольшая ошибка заключается в том, что уже упоминалось выше:
Ограничения на сериализатор (например, ограничение на публичные элементы) либо 1) налагают конструктивные ограничения на класс, который не имеет ничего общего с его основной функцией, или 2) усиливают сложность в работе над этими ограничениями.
Конечно, другие методы сериализации Xml также увеличивают сложность.
Таким образом, я думаю, что мой ответ заключается в том, что нет правильного или неправильного ответа, который подходит для всех ситуаций; выбор метода сериализации - это всего лишь одно соображение дизайна среди многих других.
которые «стандартные классы»? Этот вопрос нуждается в уточнении. –
@DDavies: Я считаю, что он имеет значение с XmlDocument, XmlElement, XmlAttribute и т. Д. .... т.е. совместимые со стандартами W3C классы XML. – jrista