XML 元素是否应该有分组父元素？

Question

首选哪种约定以及为什么（包括一种约定相对于另一种约定的一些优缺点）？

这个：

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

或者这个：

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

Answer 1

通常，在编程中处理 XML 时，您经常希望将其转换为程序可以使用的对象。大多数 XML 序列化程序使用元素来表示父元素的属性。

当您像上面的示例一样对它们进行分组时，序列化程序可以将其解释为单个集合或数组属性。在本例中，您将拥有一个 Company，它具有一个 Employees 属性，该属性是 Employee 对象的集合。

如果您采用第二种方式，您最终会得到一个 Company 对象，其属性名为“Employee”、“Employee2”、“ Employee3”或类似的东西。当你编程时，这不是一个好的对象设计。

Answer 2

通过特定元素来显式表示集合没有任何语义原因。最后，两份文件具有相同的含义——它们代表一家公司及其所有员工和建筑物。

然而，第一个示例还有其他好处：

• 它更具可读性，并且可以从编辑器中的大纲中受益。
• 您可以创建更严格的模式
• 更容易序列化为强类型集合
• 您可以在集合元素上指定适用于内部所有元素的属性

另一方面，第二个示例也有其自己的一些好处（尽管我确实发现这些可疑至少）：

• 更少啰嗦/使用更少的内存
• 更容易通过非 XML 工具进行处理

Answer 3

是否有可以附加到组中所有员工的属性或数据？我通常会选择第一个示例（分组元素），因为它使您可以自由地

1. 创建多个组
2. ，将数据作为一个整体附加到组，

它有点冗长，但给您带来了很多好处未来更加灵活。

Answer 4

用一个问题来回答你的问题...分组元素如何影响视觉上和编程上的可读性？

分组方法（使用 和 ）更加直观。

对于 XPath 查询来说，非分组方法更加简洁，/company/employees/employee 与 /company/employee 相比。

因此，其中一个可能有 6 个，另一个可能有 6 个。

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>

我会选择第一种格式。