Какая разница между двумя и когда я должен использовать каждый:
<person>
<firstname>Joe</firstname>
<lastname>Plumber</lastname>
</person>
против
<person firstname="Joe" lastname="Plumber" />
Спасибо
Какая разница между двумя и когда я должен использовать каждый:
<person>
<firstname>Joe</firstname>
<lastname>Plumber</lastname>
</person>
против
<person firstname="Joe" lastname="Plumber" />
Спасибо
В вашем примере есть центрированный элемент и атрибут XML, первый - элементный, второй - атрибут.
В большинстве случаев эти два шаблона эквивалентны, однако есть некоторые исключения.
Атрибут в центре
Элемент в центре
Практическая
Если вам действительно нужен размер XML, используйте атрибут каждый раз, когда это возможно, оставьте нулевой, сложный тип и node, который будет содержать большое текстовое значение в качестве элементов. Если вам все равно размер XML или у вас есть возможность сжатия во время трансакции, придерживаться элементов. Это более расширяемо.
Фон
В DOT NET XmlSerializer может сериализовать свойства объектов в атрибуты или элементы. В недавней среде WCF DataContract serializer может только сериализовать свойства в элементах и быстрее, чем XmlSerializer, причина очевидна, ему просто нужно искать пользовательские данные из элементов при десериализации.
Здесь также объясняется статья Элемент vs атрибут
Когда-нибудь в будущем, когда вы добавите свойство <address>
, вы не захотите сделать его атрибутом XML. Это связано с тем, что <address>
может быть более сложным элементом, состоящим из уличного адреса, города, страны и т.д.
По этой причине вам может понадобиться выбрать первую форму подэлемента, если вы действительно не уверены, что атрибут не должен идти намного глубже. Первая форма обеспечивает большую расширяемость в будущем.
Если вы вообще обеспокоены пространством, сжимайте свой XML.
В моей компании мы предпочли бы второй подход.
Мы думаем, что "firstname" и "lastname" являются атрибутами "person" node, а не подполями "person" node. Это тонкая разница.
По моему мнению, второй подход более краткий, а читаемость/ремонтопригодность значительно улучшена, что очень важно.
Конечно, это будет зависеть от вашего приложения. Я не думаю, что существует общее правило, которое охватывает все сценарии.
Вы также можете увидеть ответы на этот вопрос, который я задал некоторое время назад. Я нашел ответы полезными.
Атрибуты не чувствительны к порядку. Это может быть преимуществом или недостатком в зависимости от вашей ситуации.
Атрибуты не могут быть дублированы. Если "Джо" имеет два первых имени, то узлы - единственный способ пойти.
Я нашел следующую информацию, очень полезную для объяснения выбора атрибутов vs элементов коротким способом
Некоторые проблемы с использованием атрибутов:
атрибуты не могут содержать несколько значений (элементы могут)
атрибуты не могут содержать древовидные структуры (элементы могут)
атрибуты не просто расширяемы (для будущих изменений)
Атрибуты трудно читать и поддерживать. Используйте элементы для данных. Используйте атрибуты для информации, не относящейся к данным.