1

我有一个已发布给用户的 XML 模式。它有一个相当复杂的结构，但它也有一些通用元素，允许我们在不破坏已发布结构的情况下添加其他数据。

例子：

<record>
    <song>
        <name>thriller</name>
        <artist>Mike</artist>
        <genericData key="year">1980</genericData>
        <genericData key="duration">03:35</genericData>
    </song>
</record>

所以在这里我为年份和持续时间添加了两个 genericData 元素。

我们被要求向我们的结构添加更多数据，并且可能可以使用这些 genericData 元素来满足这些需求，但是这样做的缺点是什么？我知道它不会保留与数据的关系模型（这很糟糕），但是还有其他东西会卷土重来吗？它对我来说有难闻的气味。我更愿意为新数据添加特定的元素，但在更改我们的架构时会遇到阻力。

4

2 回答 2

1

“genericData”设计模式在 XML 中很常见，但在我看来，它很少是最好的解决方案。我认为人们使用它的一个原因是当他们使用诸如 JAXB 之类的数据绑定工具时：这些工具将 XML 映射到像 Java 这样的语言中的数据结构，而像 Java 这样的语言不能处理与 XML 相同级别的灵活性。如果没有数据绑定的约束（即，如果您使用为工作设计的工具处理 XML，例如 XSLT 和 XQuery），我将利用 XML 的内置灵活性（或者没有模式，或者在模式中使用通配符），也许使用命名空间来添加一定程度的规范控制：所以

<record>
    <song>
        <name>thriller</name>
        <artist>Mike</artist>
        <m:year xmlns:m="http://me.com/ns">1980</m:year>
        <m:duration xmlns:m="http://me.com/ns">03:35</m:duration>
    </song>
</record>
于 2013-10-29T09:29:46.213 回答
0

我想说，在 JSON 或 YAML 等相当轻的格式上使用 XML 的唯一令人信服的原因是 XML 的模式定义和实例验证能力。尽管 Play Framework 的 JSON 功能等例外情况存在，但您通常无法对这些较轻的格式强制实施模式。事实上，这很容易被视为一个加分项，具体取决于用例。这是“无模式”NoSQL 数据库的卖点之一。

如果您非常放松您的 XML，以至于架构几乎是偶然的，那么根据您的用例，这可能是完全合法的。但如果是这样，您就失去了使用 XML 的唯一令人信服的理由。

我建议确保您的通用数据的“特殊”案例确实很少见。会自然地倾向于放松你必须抵制的规则。但是，如果在仔细考虑之后您觉得模式过于严格，那么我会建议完全放弃 XML。只要知道您将把负担转移给您的团队来处理 XML 开箱即用的逻辑。

于 2013-10-29T05:07:31.347 回答