为我自己的商店和检索使用 Delphi 文本 DFM 格式的寿命答案

【问题标题】：Longevity of using the Delphi text DFM format for my own store and retrieve为我自己的商店和检索使用 Delphi 文本 DFM 格式的寿命
【发布时间】：2011-05-09 11:46:38
【问题描述】：

随着时间的推移，我推出了自己的格式来保存和加载对象属性，但在不得不重新审视这一点时，我想知道使用 Delphi 自己的文本 DFM 格式。我知道这确实是一种“内部”格式，但它的读者现在似乎定义得很好，它可以处理所有类型的属性。有没有人知道可能的陷阱？

【问题讨论】：

标签： delphi load properties save dfm

【解决方案1】：

我不会真的说 DFM 是一种“内部格式”。当然 Delphi 在内部将它用于表单和数据模块，但是执行流式传输的 TReader 和 TWriter 类是公开可访问的，甚至是文档化的。因此，它们显然也适用于最终用户。

现在，可能的问题是当您保存流时，稍后流中的某个类发生更改，从而导致流不再兼容。如果您尝试在 D7 中打开保存在 D2007+ 中的表单（缺少属性），您可能已经在 Delphi 中看到了这一点。但即使发生了，也不是太难解决。您将得到一个异常，该异常将报告导致问题的确切属性。您还必须使用RegisterClass 注册所有要流式传输的课程。

DFM 可以二进制或文本格式存储。即使您将其存储为二进制，您也可以将其转换为文本（使用ObjectBinaryToText），一旦为文本格式，就很容易修复。

因此，由于结构的不兼容更改可能会出现问题，但这些问题与 DFM 机制本身无关，使用任何其他流式机制也会发生。

至于长寿，你仍然可以在最新的Delphi中打开用D1保存的DFM。因此，只要您牢记向后兼容性，就没有什么好担心的。

总之，任何特定格式的选择，DFM、XML、JSON、您自己的……都不会真正影响寿命。它们都需要相同级别的兼容性。

选择格式的原因更多地与以下方面的决定有关：

与其他应用程序/服务的互操作性
大小/速度/人类可读性

但你没有在问题中提到任何这些。

所以我建议使用 DFM 来代替你自己的，因为这意味着需要维护的代码更少。

【讨论】：

好答案，我赞成。但我认为“DFM 流比您自己的格式更适合未来”（您暗示）并不完全正确。高度灵活和通用的格式（如 XML、JSON 或文本键值对列表）具有出色的前向兼容性，但代价是有点麻烦和占用空间。不过，如果复杂对象的未来兼容性是一个大问题，我只会推荐那些。