Я бы не сказал, что DFM - это «внутренний формат». Конечно, Delphi использует его для форм и модулей данных, но классы TReader и TWriter, которые выполняют потоковую передачу, общедоступны и даже задокументированы. Таким образом, они явно предназначены и для конечных пользователей.
Теперь возможная проблема - когда вы сохраняете поток, а затем один из классов в потоке изменяется, так что поток больше не совместим. Возможно, вы видели это в Delphi, если пытались открыть форму, сохраненную в D2007 + в D7 (отсутствует свойство). Но даже если это произойдет, это не слишком сложно решить. Вы получите исключение, в котором будет указано точное свойство, вызывающее проблему. Вы также должны зарегистрировать все классы, которые вы хотите передавать с RegisterClass.
DFM может храниться в двоичном или текстовом формате. Даже если вы сохраните его в двоичном формате, вы можете преобразовать его в текст (используя ObjectBinaryToText), после этого в текстовом формате это легко исправить.
Итак, проблемы, с которыми вы можете столкнуться из-за несовместимых изменений в структуре, но они не имеют никакого отношения к самому механизму DFM, а также могут возникнуть при использовании любого другого механизма потоковой передачи.
Что касается долговечности, вы все равно можете открывать DFM, сохраненные с помощью D1, в последней версии Delphi. Поэтому, если вы помните об обратной совместимости, вам нечего бояться.
В заключение, выбор любого конкретного формата, DFM, XML, JSON, вашего собственного ... не влияет на долговечность. Все они требуют одинакового уровня совместимости.
Причины выбора формата больше связаны с решениями относительно:
- совместимость с другими приложениями / службами
- размер / скорость / удобочитаемость
Но вы не упомянули ни одного из этих вопросов.
Так что я предлагаю использовать DFM по своему усмотрению, так как это будет означать меньше кода для обслуживания.