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

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

Я думаю, что удобочитаемость, гибкость и масштабируемость являются важными факторами. Рассмотрим следующий фрагмент 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))));

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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