随着时间的推移，我已经推出了自己的格式来保存和加载对象属性，但在必须重新访问时，我想知道是否使用 Delphi 自己的文本 DFM 格式。我知道这确实是一种“内部”格式，但它的读者现在似乎定义得很好，并且它可以处理所有类型的属性。有人对可能的陷阱有任何评论吗？
我并不是真的说 DFM 是一种“内部格式”。当然，Delphi 在内部将其用于表单和数据模块，但执行流处理的 TReader 和 TWriter 类是可公开访问的，甚至可以记录在案。因此，它们显然也是面向最终用户的。
现在，可能的问题是，当您保存流时，流中的类之一发生更改，导致流不再兼容。如果您尝试在 D7 中打开保存在 D2007+ 中的表单（缺少属性），您可能已经在 Delphi 中看到了这一点。但即使发生了，解决起来也不难。您将收到一个异常，该异常将报告导致问题的确切属性。您还必须注册您想要直播的所有课程RegisterClass.
DFM 可以以二进制或文本格式存储。即使您将其存储为二进制，您也可以将其转换为文本（使用ObjectBinaryToText），一旦采用文本格式，就很容易修复。
因此，您可能会因结构中的不兼容更改而发生问题，但这些问题与 DFM 机制本身无关，并且使用任何其他流机制也会发生。
至于寿命，您仍然可以在最新的 Delphi 中打开用 D1 保存的 DFM。因此，只要您牢记向后兼容性，就没有什么可担心的。
总之，选择任何特定格式（DFM、XML、JSON、您自己的......）并不会真正影响寿命。它们都需要相同级别的兼容性。
选择格式的原因更多地与以下方面的决策有关：
- 与其他应用程序/服务的互操作性
- 大小/速度/人类可读性
但你在问题中没有提到任何一个。
因此，我建议使用 DFM 来替代您自己的 DFM，因为这意味着需要维护的代码更少。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
