Что плохого в создании XML с конкатенацией строк?

В потоке Что ваш любимый "незнакомец программиста" заглядывает?, появляется следующий ответ с большим количеством upvotes:

Programmers who build XML using string concatenation.

Мой вопрос: зачем строить XML с помощью конкатенации строк (например, StringBuilder на С#)?

Я делал это несколько раз в прошлом, так как иногда это самый быстрый способ добраться от точки A до точки B, когда приходите к структурам данных/объектам, с которыми я работаю. До сих пор я придумал несколько причин, почему это не самый лучший подход, но есть ли что-то, что я пропускаю? Почему этого следует избегать?

Вероятно, самая большая причина, по которой я могу думать, - это избавиться от своих строк вручную, и большинство новых программистов (и даже некоторых опытных программистов) забудут об этом. Это будет отлично работать для них, когда они проведут проверку, но тогда "случайным образом" их приложения не удастся, когда кто-то выбросит символ и символ в их входе. Хорошо, я куплю это, но очень легко предотвратить проблему (SecurityElement.Escape, чтобы назвать ее).
Когда я это делаю, я обычно опускаю объявление XML (т.е. <?xml version="1.0"?>). Это вредно?
Пункты исполнения? Если вы придерживаетесь правильной конкатенации строк (т.е. StringBuilder), это все, о чем нужно беспокоиться? Предположительно, класс, подобный XmlWriter, также должен будет немного обработать строки...
Есть более элегантные способы генерации XML, такие как использование XmlSerializer для автоматической сериализации/десериализации классов. Хорошо, согласен. У С# есть много полезных классов для этого, но иногда я не хочу создавать класс для чего-то действительно быстрого, например, записывать файл журнала или что-то в этом роде. Это только я ленив? Если я делаю что-то "реальное", это мой предпочтительный подход для работы с XML.

Ответ 1

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

Ответ 2

Я считаю, что важными факторами являются читаемость, гибкость и масштабируемость. Рассмотрим следующий фрагмент Linq-to-Xml:

XDocument doc = new XDocument(new XDeclaration("1.0","UTF-8","yes"),
   new XElement("products", from p in collection
    select new XElement("product",
        new XAttribute("guid", p.ProductId), 
        new XAttribute("title", p.Title),
        new XAttribute("version", p.Version))));

Можете ли вы найти способ сделать это проще, чем это? Я могу вывести его в браузер, сохранить его в документе, добавить атрибуты/элементы за считанные секунды и т.д.... просто добавив пару строк кода. Я могу делать практически все с ним без особых усилий.

Ответ 3

На самом деле, я нахожу, что самая большая проблема с конкатенацией строк - это не исправление в первый раз, а правильное сохранение кода во время обслуживания кода. Слишком часто отлично написанная часть XML с использованием строки concat обновляется для удовлетворения нового требования, а строковый конкат-код слишком хрупкий.

Пока альтернативы были сериализацией XML и XmlDocument, я мог видеть аргумент простоты в пользу строки concat. Однако с тех пор XDocument et. al., просто нет причин использовать строку concat для сборки XML. См. Ответ Sander для наилучшего способа записи XML.

Другим преимуществом XDocument является то, что XML на самом деле довольно сложный стандарт, и большинство программистов просто этого не понимают. В настоящее время я имею дело с человеком, который отправляет мне "XML", в комплекте с неуказанными значениями атрибутов, отсутствующими тегами, неправильной чувствительностью к регистру и неправильным экранированием. Но поскольку IE принимает его (как HTML), он должен быть прав! Вздох... Во всяком случае, суть в том, что конкатенация строк позволяет вам что-либо писать, но XDocument будет принудительно выполнять стандарты, соответствующие XML.

Ответ 4

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

Я видел несколько проблем с документами XML, которые могут быть напрямую связаны с созданием документов XML вручную с использованием конкатенации строк и почти всегда вокруг правильного использования кодировки.

Спросите себя об этом; какой набор символов я кодирую в настоящее время в моем документе ('ascii7', 'ibm850', 'iso-8859-1' и т.д.)? Что произойдет, если я напишу строковое значение UTF-16 в документе XML, который был объявлен вручную как "ibm850"?

Учитывая богатство поддержки XML в .NET с XmlDocument, и теперь, особенно с XDocument, должен быть серьезный аргумент в пользу того, что вы не используете эти библиотеки для базовой конкатенации строк IMHO.

Ответ 5

Я думаю, что проблема в том, что вы не смотрите xml файл как предмет хранения логических данных, а как простой текстовый файл, в котором вы пишете строки.

Очевидно, что эти библиотеки выполняют строковые манипуляции для вас, но чтение/запись xml должно быть чем-то похожим на сохранение данных в базу данных или что-то логически подобное

Ответ 6

Если вам нужен тривиальный XML, тогда это нормально. Его просто ремонтируемость конкатенации строк ломается, когда xml становится больше или сложнее. Вы платите либо в процессе разработки, либо во время обслуживания. Выбор за вами всегда - но история предполагает, что обслуживание всегда более дорогостоящее, и поэтому все, что облегчает его, стоит в целом.

Ответ 7

Вам нужно избегать строк. Это так. Но это все? Конечно, вы можете поместить спецификацию XML на свой стол и дважды проверять каждый раз, когда вы рассматриваете все возможные угловые случаи, когда вы строите строку XML. Или вы можете использовать библиотеку, которая инкапсулирует это знание...

Ответ 8

Еще один момент против использования конкатенации строк заключается в том, что иерархическая структура данных нечеткая при чтении кода. Например, в примере @Sander Linq-to-XML ясно, какой родительский элемент принадлежит элементу "продукт", к какому элементу применяется атрибут "title" и т.д.

Ответ 9

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

"Быстро перейти от точки A к точке B". И тогда вам нужно что-то изменить...

Нет, спасибо, а не моей команде.

Ответ 10

Как вы сказали, просто неудобно правильно строить XML с использованием конкатенации строк, особенно теперь у вас есть XML linq, который позволяет просто построить график XML и получить правильные пространства имен и т.д.

Очевидно, что контекст и то, как он используется, например, в строке примера ведения журнала. Формат может быть вполне приемлемым.

Но слишком часто люди игнорируют эти альтернативы при работе со сложными графами XML и просто используют StringBuilder.

Ответ 11

Основная причина: DRY: не повторяйте себя.

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

Ответ 12

Возможно, этого никогда не произойдет, но что, если ваша среда когда-нибудь переключится на XML 2.0? Ваш связанный с строкой XML может быть или не быть действительным в новой среде, но XDocument почти наверняка сделает все правильно.

Хорошо, это досягаемость, но особенно если ваш XML, не совместимый со стандартами, не указывает объявление XML-версии... просто говоря.

Ответ 13

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

И затем загружаю его с использованием дерева XMLReader. И если XML файл не читается как действительный, я возвращаюсь и обнаруживаю проблему в моих программах сохранения и исправляю ее. Но пока я не получу рабочую систему сохранения/загрузки, я отказываюсь выполнять критически важную работу, пока не узнаю, что мои инструменты прочны.

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

Потому что независимо от того, используете ли вы StringBuilder или XMLNodes для сохранения/чтения вашего файла, если все это бесполезно, никто не поймет, как это работает.