将 XML 建模为对象还是 XML？答案

【问题标题】：Model XML as objects or as XML?将 XML 建模为对象还是 XML？
【发布时间】：2016-04-09 13:32:09
【问题描述】：

在阅读 XML 时，我应该尝试对对象建模（在 OO 意义上）还是将内容保留为 XML 实体？

在使用面向对象语言阅读“强类型”（基于模式）XML 内容时，我试图在两种方法之间做出选择：

首先，我将创建一个类型化的类层次结构来表示该模式的每个可能的元素类型及其类型化属性和所有内容。然后，当我解析一个文档时，我会递归地扫描每个节点并创建一个适当的类实例，复制所有的嵌套、属性、子项（作为集合）等。然后，我可以在我的应用程序中随意操作这个对象树，当保存回来时，我必须调用对象的toXml() 方法，或者以某种方式将对象“转换”回 XML 格式。
使用一些现成的 XML 库（任何高级语言都有一个或多个），我会解析文档并将其结构保存在内存中。那将意味着一棵节点树。然后我会直接操作它们，并可以使用库方法将所有内容保存回文件。此外，如果我的应用程序需要数据的表示，我可以创建其属性和方法实际上是指底层 Node 结构的代理对象。

问题是：通常是如何完成的？是否有一种“正确”的方式在 XML 和 OO 之间进行映射并返回？ OO 是否应该使用 XML 的众所周知的方式，或者 OO 应该使用 XML 的方式？

【问题讨论】：

标签： xml oop language-agnostic

【解决方案1】：

您的 #1 正在重塑 JAXB。你的#2 正在重塑DOM。

当您希望针对您的域的 OO 表示进行操作时，请使用 #1。

当您希望针对您的域的 XML 表示进行操作时，请使用 #2。也可以考虑作为 #2 的替代方案：

基于事件的 XML 解析器
基于 XSLT 的 XML 转换

注意不要仅仅因为熟悉而滑入第一名。 #1 的真正理由应该基于将 OO 设计作为架构核心的合理需求。 XML 到 XML 的映射，即使是复杂的映射，也不需要经过中间的 OO 表示，除非在 OO 领域中必须进行大量处理。仅在 XSLT 中就可以优雅地处理纯 XML 到 XML 的转换。

【讨论】：

非常好，谢谢！我实际上对 KML 文件格式和架构感兴趣。该应用程序将是一个地图编辑应用程序，我将在其中显示和编辑几何图形，在树视图中重新组织元素，拆分和合并文件。非常类似于 Google MyMaps。我相信实际上不需要对象模型，因为 KML 的数据类型已经相当全面。不过，我肯定需要在 View-Model 风格的架构中拥有“视图对象”，但没有什么能阻止直接使用 XML 模型作为模型，使用 GUI 工具包原语实现 View。你怎么看？
另外，如果您不介意的话，我被您对“OO 表示”和“XML 表示”作为表示域的两种几乎相互排斥的方式之间的反对所吸引。您会推荐任何资源，以便我可以在更抽象/概念级别上研究这两个设计选项吗？我相信这是隐藏在我的问题中的真正问题，我会说这是我必须首先解决的问题，其他一切都会随之而来。
（对不起，我还有一个问题：）当您说“基于事件的解析器是您的域的 XML 表示的替代方案”时，我只能想到“SAX 与 DOM”。我相信 DOM 是创建内存中、可编辑的 xml 文件版本的完美方式，因此适合表示域结构。此外，在我的阅读中，SAX 和 DOM 的呈现方式完全相反。如果您足够关心详细说明，我将不胜感激！ :o)
KML：是的，可能共享模型，但代码在 XML 之外。 OO vs XML：面向记录的数据支持 OO，面向文档的数据支持 XML。 SAX vs DOM 很好理解——只是为了将您的考虑扩展到 DOM 之外的其他 XML 处理模型。祝你好运。

【解决方案2】：

如果您使用 XML 作为对象的序列化格式，则第一种方法很有意义。在这种情况下，XML 将包含创建对象结构的所有信息。对象和 XML 节点之间应该存在一对一的映射，并且每个对象都应该负责将自己与 DOM 数据相互转换。

如果您的对象只需要来自 XML 的部分信息，则第二种方法会更好。另一个用例是遗留的 XML 模式，可能存在设计缺陷，您不想直接映射到对象结构。

顺便说一句，对于这两种方法，我强烈建议使用现成的 XML 库。我不知道你为什么认为这只能用于第二个。

【讨论】：

感谢您的回答。好吧，虽然我没有在问题中写它，但我也会在第一种方法中使用库，但我的意思是方法之间的区别是从较低级别的 xml-parser 调用（SAX像遍历），并将对象树管理委托给应用程序，而不是将底层对象结构表示留给来自库的更高级别的单遍“解析”结果。