我有一个应用程序，它以基于 Xml 的格式保存文档（例如 Word 文档） - 目前，从 xsd 文件生成的 C# 类用于读取/写入文档格式，一切都很好，直到最近我不得不更改以下格式：该文件。我担心的是我的应用程序的未来版本的向后兼容性need能够读取所有以前版本保存的文档，理想情况下，我还希望我的应用程序的旧版本能够优雅地处理读取我的应用程序的未来版本保存的文档。
例如，假设我更改文档的架构以在某处添加（可选）额外元素，那么我的应用程序的旧版本将简单地忽略额外元素，并且不会出现问题：
<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 程序集版本匹配，或者应该使用更复杂的策略（例如，主要修订版更改表示重大更改，而次要修订版增量表示非重大更改 - 例如额外的可选元素）
- What method should I use to read the document itself and how do I avoid replicating massive amounts of code for different versions of documents?
- 虽然 XPath 显然是最灵活的，但它比简单地使用 xsd 生成类要实现更多的工作。
- 另一方面，如果使用 DOM 解析，则每个重大更改都需要在源代码管理中生成文档 xsd 的新副本，如果需要将修复应用于旧模式（仍支持旧版本的应用程序），则会导致问题。
另外，我非常松散地假设我所做的所有更改都可以分为“喙状更改”和“非破坏性更改”这两类，但我并不完全相信这是一个安全的假设使.
请注意，我非常宽松地使用“文档”一词 - 内容根本不像文档！
感谢您能给我提供的任何建议。
您肯定需要 XML 文件中的版本号，我建议不要将其与应用程序的版本绑定，因为它实际上是一个单独的实体。您可能会使用应用程序的两个或三个版本而无需更改 XML 格式，或者您可能会在单个版本的开发过程中多次更改格式。
如果您希望旧版本的应用程序能够读取新版本的 XML 文件，那么您永远不能删除元素或更改它们的名称。您始终可以添加元素，旧代码会很乐意忽略它们（XML 的优秀功能之一），但如果删除它们，则旧代码将无法运行。
正如 Ishmael 所说，XSLT 是将 XML 格式从一个版本转换为另一个版本的好方法，这样您就不会在源代码中遇到一大堆解析例程。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
