Должны ли элементы XML группировать родителей?

Question

Какое соглашение было бы предпочтительным и почему (включая некоторые плюсы и минусы одного из них)?

Это:

<company> 
    <employees> 
     <employee /> 
     <employee /> 
     <employee /> 
    </employees> 
    <buildings> 
     <building /> 
     <building /> 
    </building> 
</company> 

или это:

<company> 
    <employee /> 
    <employee /> 
    <employee /> 
    <building /> 
    <building /> 
</company> 

Answer 1

Нет семантических причин для явного представления коллекции через определенный элемент. В конце концов, оба документа имеют одинаковое значение - они представляют собой компанию со всеми ее сотрудниками и зданиями.

Однако, есть дополнительные преимущества, первый пример предложение:

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

С другой стороны, второй пример также имеет некоторые преимущества своей собственной (хотя я нахожу эти сомнительны, по крайней мере):

• меньше болтливый/использует меньше памяти
• легче обрабатывать с помощью инструментов, отличных от XML.

Answer 2

Есть ли атрибуты или данные, которые вы могли бы приложить к всех сотрудников в группе? Я обычно иду на первый пример (группировка элементов), так как он дает вам свободу

1. создать несколько групп
2. крепят данные к группе в целом

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

Answer 3

Чтобы ответить на ваш вопрос вопросом ... Как элементы группировки влияют на читаемость, как визуально, так и программно?

Сгруппированный метод (с <employees> и <buildings>) более наглядный.

Негрупповой метод является немного более кратким для запроса XPath, /company/employees/employee против /company/employee.

Таким образом, это может быть 6 из одного, полдюжины других.

Answer 4

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

Когда вы группируете их, как в своем верхнем примере, сериализаторы могут интерпретировать это как одно свойство коллекции или массива. В этом случае у вас будет Company, у которого есть свойство Employees, которое представляет собой набор объектов Employee.

Если вы делаете это второй путь, вы будете в конечном итоге с Company объекта со свойствами под названием «Employee», «Employee2», «Employee3» или что-то подобное. Когда вы программируете, это не очень хороший дизайн объекта.

Answer 5

Я бы подошел к нему, подумав о том, какие данные вы представляете.

В C#, я вижу это:

// Top Example: 
public class Company 
{ 
    public Employee[] employees; 
    public Building[] buildings; 
} 

// Vs. Bottom Example: 
public Things[] employeesAndBuildings; 

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

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

<company> 
    <employee /> 
    <building /> 
    <employee /> 
    <building /> 
    <employee /> 
</company> 

Я бы для первого формата.