Интеграция является важной частью любого приложения B2B, а XML является распространенным (IMHO хорошим) способом передачи данных между системами. Как правило, одна сторона должна сделать грязную работу по интеграции. Обычно это небольшая компания, в которой по тем или иным причинам я всегда работаю. Схемы БД могут быть болезненными для изменения, но схемы XML, особенно те, которые выставлены внешне, почти невозможно изменить. В свое время , я видел схему из ада , которые сделали меня хотят рвать на себе волосы и разрушенная , что могло бы быть очень хороший днем. Вот список того, что я считаю преступлениями XML.
Отсутствие схемы XML
Всякий раз, когда вы работаете с XML, у вас всегда должна быть схема. Это ‘Совершенно неуместно и непрофессионально распространять XML извне и не предоставлять схему (предпочтительно XSD ). Я удивлен, как часто я вижу людей, работающих с XML без схемы . Как еще вы собираетесь документировать и проверять свой XML? Не говоря уже о завершении кода и автогенерации.
Имея элементы, содержащие только атрибуты
Атрибуты , предназначенные для описания Свойс х годов этого элемента, в основном их метаданных [1] . Иногда люди путаются и помещают все данные в атрибуты.
например
<artist name="Arcade Fire" country="Canada" type="Band"/>
Гораздо лучший способ представить эти данные:
<artist type="band">
<name>Arcade Fire</name>
<country>Canada</country>
</artist>
Почему это лучше? Во — первых , это « S так , как это было задумано, во- вторых, » s легче разобрать, и , наконец, ‘ s более расширяемой. Ключевым компонентом взаимодействия является согласованность: одни значения в атрибутах, а другие в элементах нарушают это правило.
Неправильная кодировка символов.
Кажется, что большинство разработчиков не понимают, что такое кодировка символов . Если у вас нет очень веской причины, все XML должны быть закодированы как UTF-8 . Вы всегда должны добавлять декларацию XML вверху ваших документов.
например
<?XML version="1.0" encoding="UTF-8" ?>
К лучшему или худшему, символы ASCII обычно имеют одинаковые кодовые точки в обычно используемых схемах кодирования. Это означает, что проблемы с кодированием обычно не возникают, пока система не заработает; обычно «` «является виновником на платформах Window. То, что у вас нет иностранных / странных персонажей или вы просто не заботитесь об интернационализации, не означает, что вы амнистированы за это преступление.
Еще один момент, который важно отметить, заключается в том, что добавление encoding = UTF-8 не означает, что оно закодировано как UTF-8. По умолчанию Java создает текстовые файлы в схеме кодирования вашей ОС ( 1251 в Windows), и Java не является единственным соучастником этого преступления.
Элементы, содержащие разделенные поля.
Лучше всего описать на примере:
<artist>
<name>Arcade Fire</name>
<members>Win Butler, Régine Chassagne, Richard Reed Parry, William Butler, Tim Kingsbury, Sarah Neufeld, Jeremy Gara</members>
</artist>
Одна из хорошей вещь сек о XML является то , что он может быть использован для отображения большинства структур данных, таких как списки в списках. Разделение полей внутри элементов показывает, что дизайнер недостаточно задумывался о будущих потребностях схемы или не понимает XML. Пример ниже гораздо проще сгенерировать и проанализировать.
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>
Никакой дополнительной логики не требуется, чтобы преобразовать эту структуру в полезную объектную модель. Наконец, что произойдет, если одно из ваших полей содержит символ, который используется для разделения?
Не упаковка повторяющихся элементов,
например
<artist>
<name>Arcade Fire</name>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
<album>Funeral</album>
<album>Neon Bible</album>
</artist>
Еще раз кошмар, чтобы разобрать, и это не совсем человекочитаемый. XML в этой структуре также приведет к неоднозначной схеме, которая, в свою очередь, разорится с генераторами авто-кода (например, JAXB ). Это намного лучше:
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
<albums>
<album>Funeral</album>
<album>Neon Bible</album>
</album>
</artist>
Повторение имен элементов в разных контекстах
Согласованность — это то, к чему все разработчики должны стремиться каждый день, а в чем-то столь же самодостаточном, как схема XML, это действительно не должно быть так сложно. Одно место XML-схем часто падает в именах, которые выбраны для атрибутов и элементов. В приведенном ниже примере элемент с именем «artist» появляется в двух местах, каждое из которых имеет свое значение и структуру.
например
<album>
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>
<track>
<name>Intervention</name>
<artist>Arcade Fire</artist>
</track>
</album>
Лучшая структура будет
<album>
<artist>
<name>Arcade Fire</name>
<members>
<member>Win Butler</member>
<member>Régine Chassagne</member>
<member>Richard Reed Parry</member>
<member>William Butler</member>
<member>Tim Kingsbury</member>
<member>Sarah Neufeld</member>
<member>Jeremy Gara</member>
</members>
</artist>
<track>
<name>Intervention</name>
<track-artist>Arcade Fire</track-artist>
</track>
</album>
Логическая и согласованная компоновка всегда делает синтаксический анализатор проще, а XML — более легким для чтения. Противоположность этому преступлению так же плоха, этот вариант подразумевает не использование одного и того же имени элемента / атрибута для полей, которые явно совпадают. Например, элементы «name» и «track-name» в приведенном ниже примере.
<album>
<artist>
<name>Arcade Fire</name>
</artist>
<track>
<track-name>Intervention</track-name>
</track>
</album>
Гораздо более логичная структура — использовать один и тот же элемент «name» в обоих местах.
<album>
<artist>
<name>Arcade Fire</name>
</artist>
<track>
<name>Intervention</name>
</track>
</album>
Сокращение имен элементов / атрибутов
Да XML очень многословен, и файлы могут стать очень большими, но сокращение имен элементов или атрибутов для экономии места не является хорошей идеей.
<a>
<n>Arcade Fire</n>
</a>
Во-первых, если вы беспокоитесь о размере, почему вы используете XML? Во-вторых, XML содержит много повторяющегося текста, поэтому он хорошо сжимается. Этот XML определенно не читается человеком, и любой код, который работает с ним, будет сложнее поддерживать.
Поиск значения ключа
Худшая XML-схема, которую я когда-либо видел. Я думаю, что пример достаточно описания
<root>
<entry>
<key>Artist</key>
<value>Arcade Fire</value>
</entry>
<entry>
<key>Country</key>
<value>Canada</value>
</entry>
</root>
Это действительно бросает вызов всему, что представляет XML, вы можете просто иметь простой текстовый файл.
Вывод
При разработке схемы XML придерживаются следующих двух правил:
- Убедитесь, что XML является машиночитаемым
- Убедитесь, что XML читается человеком
Пожалуйста, если вы когда-либо проектировали XML-схему, помните, что и машины, и люди должны иметь возможность легко читать XML. Просто подумайте немного об этом и не делайте то, что проще всего сейчас, иначе другим придется смириться с вашими преступлениями.