随着时间的推移，我已经推出了自己的格式来保存和加载对象属性，但是由于不得不重新审视这个，我想知道使用Delphi自己的文本DFM格式。我知道这实际上是一种“内部”格式，但现在它的读者看起来非常明确，它可以应对所有类型的财产。有没有人对可能的陷阱有任何评论？
答案 0 :(得分：16)
我不会说DFM是'内部格式'。 Sure Delphi在内部使用它来表单和数据模块，但执行流式传输的TReader和TWriter类可以公开访问，甚至可以记录。因此，它们显然也适用于最终用户。
现在，可能的问题是当您保存流时，稍后流中的某个类发生更改，以使该流不再兼容。如果您尝试在D7中打开保存在D2007 +中的表单（缺少属性），您可能已经在Delphi中看到了这一点。但即使它发生了，也不难解决。您将获得一个异常，该异常将报告导致问题的确切属性。您还必须使用RegisterClass注册要传输的所有类。
DFM可以二进制或文本格式存储。即使你存储二进制文件，你也可以将其转换为文本（使用ObjectBinaryToText），一旦文本格式，它就很容易修复。
因此，由于结构中的不兼容更改，您可能会遇到问题，但这些问题与DFM机制本身无关，也可能使用任何其他流机制发生。
至于长寿，你仍然可以在最新的Delphi中打开用D1保存的DFM。因此，只要你保持向后兼容性，就没什么可担心的了。
总之，任何特定格式，DFM，XML，JSON，您自己的选择......都不会影响寿命。它们都需要相同级别的兼容性。
选择格式的原因更多与决策有关：
但你没有提到问题中的任何一个。
所以我建议使用DFM over roll自己，因为这意味着需要维护更少的代码。