Как организовать импорт и экспорт кода для версионных файлов? - PullRequest
1 голос
/ 10 февраля 2011

Если приложение должно иметь возможность открывать (и, возможно, сохранять) формат файла для последних N выпусков, как должен быть организован разумный код, чтобы обновление формата файла было простым и менее подверженным ошибкам?Предположим, что формат файла в XML, и функции принимают объекты для экспорта и создают объекты для импорта.

Добавляют число в конец каждого имени функции, копируют / вставляют его и увеличивают число для каждого новоговерсия?Это похоже на поддержку нескольких версий функций с управлением версиями в исходном коде.Может быть, какое-то волшебство во время сборки?

Ответы [ 2 ]

3 голосов
/ 10 февраля 2011

Во-первых, поддержка импорта старых версий намного проще, чем экспорт.Это потому, что обычно более поздние версии отличаются, потому что они поддерживают больше функций.Следовательно, сохранение в старом формате может означать потерю данных.Следовательно, мой опыт заключается в поддержке импорта нескольких версий, охватывающих более десяти лет.

XML, конечно, является разумным решением.Он разработан с учетом этой проблемы.Ключевым моментом для меня является то, что чистая структура кода следует из чистой модели данных.При условии, что в новых версиях добавлены функции, и они представлены поддержкой дополнительных тегов, вам вообще не нужно перекодировать обработку существующих тегов.

Теперь вы можете изменить семантику существующих теговтребуя их перекодировки.Решение: не делайте этого, если можете этого избежать.Когда вы добавляете атрибут или тег, убедитесь, что вы определили значение по умолчанию, а затем старые и новые файлы данных обрабатываются без проблем.

Так что мне кажется, что с осторожностью вы сможете избежать многих случаев, когда выдействительно имеют существенно различный код для обработки одних и тех же полей в разных версиях файлов.Там, где это происходит, я предполагаю, что есть «особые обстоятельства» (это жизнь с программным обеспечением).При разработке универсального решения вы будете иметь в виду конкретные варианты использования, и такие особые случаи могут не обрабатываться в любом случае.

В заключение: вы будете наиболее эффективны в будущем, определив путь обновления данныхмодель.

1 голос
/ 10 февраля 2011

Возможно, требуется номер версии.

Но лучше всего сделать дизайн для вашего XML. И убедитесь, что XML структурирован интуитивно понятным и естественным образом. В противном случае текущая организация вашего кода может просочиться в структуру XML, что затруднит чтение XML для будущих версий вашего продукта.

При сохранении перечисляемых значений пишите не числа, а имя перечислимого. Если в принципе некоторые элементы могут встречаться несколько раз, но не в вашем текущем приложении, спроектируйте его как массив в XML. Убедитесь, что числа, которые вы пишете, находятся в логической единице в проблемной области, а не в том, что ваше приложение использует сейчас.

В XML, написанном таким образом, не должно быть сложно поддерживать унаследованные версии вашего XML.

Edit:

Если вы вносите радикальные изменения, может быть полезно просто реализовать устаревший объект данных, который читает устаревший xml. Затем вы пишете метод преобразования для преобразования старой модели данных в новую. Это поможет вам начать новую жизнь ESP. если старая модель данных была плохо спроектирована.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...