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

Question

我有一个应用程序，它以基于 Xml 的格式保存文档（例如 Word 文档） - 目前，从 xsd 文件生成的 C# 类用于读取/写入文档格式，一切都很好，直到最近我不得不更改以下格式：该文件。 我担心的是向后兼容性，因为我的应用程序的未来版本需要能够读取所有以前版本保存的文档，理想情况下我也希望我的应用程序的旧版本能够正常处理读取保存的文档通过我的应用程序的未来版本。

例如，假设我更改文档的架构以在某处添加（可选）额外元素，那么我的应用程序的旧版本将简单地忽略额外元素并且不会出现问题：

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

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

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

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

更改为：

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

为了防止将来出现支持问题，我想提出一个不错的策略来处理我将来可能进行的更改，以便我的应用程序版本我现在发布的版本将能够应对未来的这些变化：

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

另外，我非常松散地假设我所做的所有更改都可以分为“喙状更改”和“非破坏性更改”这两类，但我并不完全相信这是一个安全的假设使.

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

感谢您能给我提供的任何建议。

Answer 1

您肯定需要 XML 文件中的版本号，我建议不要将其与应用程序的版本绑定，因为它实际上是一个单独的实体。 您可能会使用应用程序的两个或三个版本而无需更改 XML 格式，或者您可能会在单个版本的开发过程中多次更改格式。

如果您希望旧版本的应用程序能够读取新版本的 XML 文件，那么您永远不能删除元素或更改它们的名称。 您始终可以添加元素，旧代码会很乐意忽略它们（XML 的优秀功能之一），但如果删除它们，则旧代码将无法运行。

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

Answer 2

XSLT 在这里是一个明显的选择。 鉴于您可以识别文档的版本，因此对于模式的每个版本，创建一个 XSLT 将以前的版本转换为新版本。

您可以按顺序应用转换，直到达到当前版本。 因此，您只能编辑最新的文档版本。 当然，您将无法保存为旧格式，并且可能会破坏旧版本的文档，但这是许多应用程序的典型情况。 如果您确实需要保存到旧版本，只需创建一个相反的转换即可。

就像@Andy 所说，使用应用程序的主要版本号。

Answer 3

您可以向根元素添加指定版本的属性吗？

这样旧版本就不会被破坏，而新版本的软件将看到该属性并适当地切换到不同的加载方法。

版本编号本身取决于您的发布频率。 我个人会选择您软件的主要内部版本号，除非您预见到格式更改的频率会更高。

编辑：刚刚注意到有关代码重复的一点：

为此我将使用工厂模式，如下所示：

LoadDocument
DoNonVersionDependingLoading
VersionSpecificLoaderFactory(VersionNumber)