c# - 我应该如何管理基于 Xml 的文档的不同不兼容格式

Question

我有一个以基于 Xml 的格式保存文档(想想 word 文档)的应用程序 - 目前从 xsd 文件生成的 C# 类用于读取/写入文档格式，直到最近我不得不进行更改时一切都很好文档的格式。我担心的是向后兼容性，因为我的应用程序的 future 版本需要能够读取所有以前版本保存的文档，理想情况下我还希望我的应用程序的旧版本能够优雅地处理读取保存的文档通过我的应用程序的 future 版本。

例如，假设我更改文档的架构以在某处添加一个(可选的)额外元素，那么我的应用程序的旧版本将简单地忽略额外的元素并且不会有任何问题:

<doc>
    <!-- Existing document -->
    <myElement>Hello World!</myElement>
</doc>

但是，如果进行了重大更改(例如，属性更改为元素或元素集合)，那么我的应用程序的过去版本应该忽略此元素(如果它是可选的)，或者通知用户他们正在尝试读取用我的应用程序的较新版本保存的文档，否则。这也让我很头疼，因为我的应用程序的所有 future 版本都需要完全独立的代码来读取两个不同的文档。

此类更改的一个示例是以下 xml:

<doc>
    <!-- Existing document -->
    <someElement contents="12" />
</doc>

更改为:

<doc>
    <!-- Existing document -->
    <someElement>
        <contents>12</contents>
        <contents>13</contents>
    </someElement>
</doc>

为了防止将来出现令人头疼的支持问题，我想提出一个合理的策略来处理我将来可能做出的更改，以便我现在发布的应用程序版本能够处理这些问题 future 的变化:

• 文档的“版本号”是否应存储在文档本身中，如果是，应使用何种版本控制策略？如果文档版本与 .exe 程序集版本匹配，或者应该使用更复杂的策略，(例如，主要修订更改表示中断更改，而次要修订增量表示非中断更改 - 例如额外的可选元素)
• 我应该使用什么方法来阅读文档本身以及如何避免为不同版本的文档复制大量代码？
  • 虽然 XPath 显然是最灵活的，但它的实现比简单地使用 xsd 生成类要多得多。
  • 另一方面，如果使用 DOM 解析，则在源代码管理中需要为每个重大更改提供一份新的 xsd 文档副本，如果需要将修复应用于旧模式(旧版本的应用程序是仍然支持)。

此外，我在假设我所做的所有更改都可以分为“基本更改”和“非破坏性更改”这两个类别的情况下非常松散地处理了所有这些，但我并不完全相信这是一个安全的假设。

请注意，我对“文档”一词的使用非常宽松 - 内容根本不像文档!

感谢您给我的任何建议。

Answer 1

您肯定需要 XML 文件中的版本号，我建议不要将它与应用程序的版本绑定(bind)，因为它实际上是一个单独的实体。您可以在不更改 XML 格式的情况下开发您的应用程序的两个或三个版本，或者您可能最终在单个版本的开发过程中多次更改格式。

如果您希望旧版本的应用程序能够读取新版本的 XML 文件，那么您永远不能删除元素或更改它们的名称。您可以随时添加元素，旧代码会愉快地忽略它们(XML 的一个很好的特性)，但如果您删除它们，旧代码将无法运行。

正如 Ishmael 所说，XSLT 是一种将 XML 格式从一个版本转换为另一个版本的好方法，这样您就不会在源代码中得到一大堆解析例程。