3

我必须指定一个 JSON 数据结构；该数据结构将成为接口描述的一部分，数据将由 JavaScript 处理。为数据传输设置了 JSON。在其他项目中，我们使用 XML 而不是 JSON，为此我使用了丰富的 XML 模式。不幸的是，我现在不能这样做。

我做了一些研究，发现了JSON Schema。但是，这仍然是草稿状态，这让我在这种情况下使用它感到有些不安。

我还遇到了这个问题，讨论如何将 XML 映射到 JSON。org.json 命名空间中的XML 类中似乎有一个标准 (?) 转换。对于没有混合内容的 XML 文档，转换似乎相当简单。

所以想法是使用 XML Schema 来描述数据结构，尽可能在服务器端使用我们现有的 XML 处理（编辑、转换、验证……）工具，并在交付之前将 XML DOM 转换为 JSON数据到 JSON 消费者。

数据传输只是单向的，我们不会有混合内容的 XML。

也许有人以前试过这个？当（概念上）应用于 JSON 文档时，从 XML Schema 的语义对于客户端程序员来说仍然足够清晰的意义上来说，这是否是一种实用的方法？有什么特别的陷阱需要注意吗？

4

2 回答 2

2

如果我理解你的想法是正确的，你想使用 XML Schema 作为你数据交换的主要模型——用于 XML 以及 JSON 格式。

这个想法有两个部分：

  • 使用单一来源对所有数据交换进行建模。
  • 使用 XML Schema 作为这个单一来源。

单源型号

第一个想法将您带到 MDD（模型驱动开发）或 MDA（模型驱动架构），它们在 2002-2005 年左右大肆宣传。这是大量 UML、供应商驱动的炒作，但有不少合理的东西（如AndroMDA）幸存下来。

一般来说，MDA 是一个好主意。只要你做“标准”的事情，它就可以很好地工作。但如果你想“定制”，这可能是一场噩梦。

在您的情况下，我肯定会说单源模型是有道理的。这是关于数据交换的。在核心中，这可以简化为非常简单的模型，这些模型仍然足够强大，可以表达你需要的一切。

JSON 就是一个例子。JSON 比 XML 更简单，但仍然足够强大。它清楚地表明，只要你有基本的原始类型、对象、数组和嵌套，你几乎可以表达任何东西。

这种“单一源模型”不一定是 UML，它可以是任何强大到足以涵盖所有底层需求的东西。

“单源模型”的主要问题是定制。你知道，90% 的 OOTB 效果很好，但是在 10% 中你没有得到你想要的结果，必须定制，然后努力得到你。大多数生成工具都有一些“插件”。因此，如果您符合 90% 的要求，那么您很幸运，否则您可能需要了解生成工具的复杂内部结构。

总而言之，单源模型是一个好主意，只要它满足所有需求，并且为所需场景调整/应用它​​的努力并不比从头开始制作更大。

XML Schema 作为模型

下一个问题是 XML Schema 是否适合作为单一源模型。

您可能听说过或使用过具有模式编译器(XJC)的JAXB 。此编译器可以获取您的 XML 模式，然后生成带有 JAXB 注释的 Java 类。然后可以使用这些类将 XML 解组为 Java 对象或将这些对象编组为 XML。

对于 JSON：

JAXB 映射到 JSON

看起来您也可以从这些类中生成 JSON Schema（虽然我自己没有尝试过）：

如何从 JAXB 注释类生成 JSON 模式？

所以 XML Schema-first 方法有效。您可以将其称为模式驱动开发（我在此声明该术语的版权）。

我个人做了很多事情，首先为 XJC 写了一些工具/插件。例如：

我的经验是，您可以先做很多事情，但我也不得不说 XML Schema 很好，但不是最好或最简单的模型。该规范很复杂，如果您查看模式派生类，那么您会发现一些不太适合 Java bean 和属性的构造。例如，@XmlElementRef它是一个复杂且通常看起来很奇怪的构造——它仍然是涵盖许多您可以在 XML 模式中轻松表达的情况所必需的。在我编写的所有工具中，我总是不得不与此类构造的案例和案例以及角落案例的角落案例作斗争。

XML Schema，如果你保持简单和整洁，可能会很漂亮。映射完美的 bean 和属性，易于理解和使用，大量的工具支持。所以XML Schema 并不是建模或指定数据交换的最差选择。

但它也可能变得非常复杂。我看到了很多过度设计的模式，它们非常难以使用 - 收获很少。有时模式设计者只是不太了解 XML 模式，有时却太了解它了。上次我帮助制定“XML Schema 设计最佳实践”时，我们找到了 60 多页的“注意事项”文档。所以很容易弄错 XML Schemas。

但是，正如我上面所说，如果它保持简单和干净，它可能会很漂亮。

有哪些替代方案？

好吧，您实际上可以使用您的 Java 代码作为模型源。带注释的 POJO 在表达上足够强大且用途广泛，但使用起来仍然非常简单。您不是模式优先，而是 Java 代码优先，但您仍然可以执行所有相同的技巧。您可以根据带注释的类生成 XML 模式。您可以使用MOXy进行持久性（以及更多）。你也可以做JSON 。

总结并回答您的问题：

  • 是的，它很实用，而且效果很好。
  • 除了模式优先的方法，还要考虑 Java 优先的方法。
  • 您拥有获取 XML-Objects-JSON-Persistence 的工具。
  • 有陷阱（见上文）。

希望这可以帮助。

于 2014-10-25T21:03:57.127 回答
0

由于到目前为止还没有人回答这个问题，并且我们已经开始遵循这种方法，所以我快速总结一下，对我们来说，这种方法通常效果很好。我们设计了一个非常丰富的 XML Schema，作为服务器和 Web 客户端之间契约的一部分。JSON 一对一地遵循 XML，因此 XML Schema 也自然地读取 JSON 文档。

我们注意到的唯一小问题是，我们使用的规范 XML 到 JSON 转换（它不支持模式）在树中某处只有一个子元素时创建单个对象，即使 XML 模式有一个该元素的“许多”的上限。这意味着程序员必须在 JSON 端处理对象值和集合之间的一些多态性。

于 2014-01-11T07:14:35.093 回答