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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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