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

Question

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

Programmers who build XML using string concatenation.

Мой вопрос: почему сборка XML с помощью конкатенации строк (например, StringBuilder в C #) плоха?

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

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

Answer 1

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

Answer 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))));

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

«Чтобы быстро добраться из пункта А в пункт Б». И тогда вы должны что-то изменить ...

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

Answer 8

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

Answer 9

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

Answer 10

Основная причина: СУХОЙ: не повторяйся.

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