对象/XML 向后兼容性
我们将对象存储在 XML 中。有时我们更新基础对象，然后我们必须在文件中保存更多数据来表示对象的额外属性。
如何组织/实现一个系统以确保与旧版本文件的向后兼容性？
当同时查看多个版本时，复杂的部分就出现了。
Version 1 -> Version 2 -> Version 3 -> Version 4
我们是否应该编写四个文件读取器，每个文件版本一个，将其读入对象的当前最新版本？或者，我们是否应该保留版本 1-3 中类的所有旧版本，以便旧读者可以将数据读取到这些类中，然后使用增量更新程序来更新 1->2然后是2->3，然后是3->4。
We store objects in XML. Sometimes we update the base objects, then we have to save more data in our files to represent the extra attributes of our objects.
How to organize/implement a system to ensure backwards compatibility with old versions of our files?
The complicated part comes when looking at several versions at once.
Version 1 -> Version 2 -> Version 3 -> Version 4
Should we write four file readers, one for each version of the file to read it into the current latest version of our object? Or, should we keep all the old versions of the classes around from versions 1-3 so that the old readers can read the data into those classes, and then have incremental updaters to update 1->2 and then 2->3 and then 3->4.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当我增加这样的版本时，我通常保留旧的读者，然后更新它以写入新模型。这意味着我只有当前模型可供其余代码处理，但我仍然可以读取旧文件。我不会保留旧类，无论您可能做出什么其他选择 - 您希望将代码中必须理解旧版本的位置数量本地化为尽可能少（最好是一个） 。如果保留旧的类，那么处理这些类的任何代码（即使是从公共基础派生的）都会面临必须“了解”旧版本的风险，并且在一段时间后会造成严重的维护灾难。
这不是万能药……所有明显的选择都有问题。一旦你有多个老读者，更新它们就变得非常耗时（上帝禁止你将他们需要的一些代码重构到新的命名空间中，然后必须有效地编辑相同的代码 100 次来替换名称）。然而，我通常只是用它作为完全摆脱旧版本的门户 - 如果您决定只让一些旧版本阅读器浮动以实现向后兼容性，那么您可以在每次制作新版本时开始删除最旧的版本，使维护工作变得不再那么令人头疼。
When I increment versions like this I typically keep the old reader, and just update it to write into the new model. This means I only have the current model for the rest of my code to deal with, but I can still read old files. I would not keep old classes around, no matter what other choices you may make - you want to localize the number of places in your code that have to understand old versions to as few as possible (preferably one). If you keep old classes around, then any code that deals with those classes (even as derived from a common base) runs the risk of having to "know" about old versions, and that creates an unmitigated maintenance disaster after a while.
This is NOT a panacea...all the obvious options have issues. Once you have more than a few old readers, it becomes really time consuming to update them all (and god forbid you refactor some code they require into a new namespace and then have to edit effectively the same code 100 times to replace names). However, I usually just use this as a gateway to getting rid of old versions entirely - if you resolve to only have a few old version readers floating around for backwards compatibility, you can start deleting the oldest ones every time you make a new one, making the maintenance considerably less of a headache.