Коллеги,
Некоторое время не дает покоя тема версионности.
Допустим, тот же MS Word. От версии к версии формат документа меняется. И очень не хотелось бы, чтобы код "для обратной совместимости" рос пропорционально кол-ву версий, ибо: новый Office выходит раз в год-два. Если же продукт обновляется раз в квартал, то ой. Посему хотелось бы узнать, кто как борется с проблемой версионности данных без потери backward compatibility.
Как показало гугление на тему schema evolution, то основных подходов два: либо фиксировать версию данных при создании (т.е. аналогично интерфейсам — однажды объявленный, он не должен меняться, можно лишь объявлять новые интерфейсы), либо делать автообновление при открытии (путем user-defined кода).
Первый подход мне не нравится тем, что проблема версионности просто эскалируется в Data Access Layer, который должен содержать набор средств по унификации/преобразованию версий данных.
Второй подход не нравится именно "рукописностью" — простыня из методов FromV1ToV2, FromV2ToV3, FromV3ToV4 почему-то не воодушевляет
Возможно, кому-то чем-то близка подобная тема — прошу поделиться пинком в нужном направлении.
Здравствуйте, Аноним, Вы писали:
А>Коллеги,
А>Некоторое время не дает покоя тема версионности.
А>Допустим, тот же MS Word. От версии к версии формат документа меняется. И очень не хотелось бы, чтобы код "для обратной совместимости" рос пропорционально кол-ву версий, ибо: новый Office выходит раз в год-два. Если же продукт обновляется раз в квартал, то ой. Посему хотелось бы узнать, кто как борется с проблемой версионности данных без потери backward compatibility.
А>Как показало гугление на тему schema evolution, то основных подходов два: либо фиксировать версию данных при создании (т.е. аналогично интерфейсам — однажды объявленный, он не должен меняться, можно лишь объявлять новые интерфейсы), либо делать автообновление при открытии (путем user-defined кода).
А>Первый подход мне не нравится тем, что проблема версионности просто эскалируется в Data Access Layer, который должен содержать набор средств по унификации/преобразованию версий данных.
А>Второй подход не нравится именно "рукописностью" — простыня из методов FromV1ToV2, FromV2ToV3, FromV3ToV4 почему-то не воодушевляет
А>Возможно, кому-то чем-то близка подобная тема — прошу поделиться пинком в нужном направлении.
У нас применяется второй описанный Вами метод. То есть если какой-то компонент системы меняет свои структуры данных, то он же и поддерживает переход от старых структур к новым, то есть FromV1ToV2, FromV2ToV3, .... Тут V1, V2, ... это внутренние версии самих структур данных конкретного компонента (а не версии всего продукта).
А чем плох такой подход (я о втором варианте в целом)? ИМХО, это сродни Save As или Convert. Или они Вам тоже не нравятся?
Здравствуйте, Максим2006, Вы писали:
М>У нас применяется второй описанный Вами метод. То есть если какой-то компонент системы меняет свои структуры данных, то он же и поддерживает переход от старых структур к новым, то есть FromV1ToV2, FromV2ToV3, .... Тут V1, V2, ... это внутренние версии самих структур данных конкретного компонента (а не версии всего продукта).
М>А чем плох такой подход (я о втором варианте в целом)? ИМХО, это сродни Save As или Convert. Или они Вам тоже не нравятся?
У нас тоже применяется такой подход. Мне не нравится
1) необходимость рисовать все эти методы руками
2) при большом количестве подобных методов наглядность кода стремится к нулю
Интересует формализация этих заморочек. Т.е. в идеале мы имеем набор правил (например, в форме XML) по конвертации данных из старого формата в новый (например, через XSLT). Таким образом, код по апгрейду данных один и тот же (или незначительно меняется в сторону расширения функционала трансформаций), ему просто скармливаются конкретные наборы правил, исходя из версии полученных данных.
Здравствуйте, Аноним, Вы писали:
А>Коллеги,
А>Некоторое время не дает покоя тема версионности.
А>Допустим, тот же MS Word. От версии к версии формат документа меняется. И очень не хотелось бы, чтобы код "для обратной совместимости" рос пропорционально кол-ву версий, ибо: новый Office выходит раз в год-два. Если же продукт обновляется раз в квартал, то ой. Посему хотелось бы узнать, кто как борется с проблемой версионности данных без потери backward compatibility.
А>Как показало гугление на тему schema evolution, то основных подходов два: либо фиксировать версию данных при создании (т.е. аналогично интерфейсам — однажды объявленный, он не должен меняться, можно лишь объявлять новые интерфейсы), либо делать автообновление при открытии (путем user-defined кода).
А>Первый подход мне не нравится тем, что проблема версионности просто эскалируется в Data Access Layer, который должен содержать набор средств по унификации/преобразованию версий данных.
А>Второй подход не нравится именно "рукописностью" — простыня из методов FromV1ToV2, FromV2ToV3, FromV3ToV4 почему-то не воодушевляет
А>Возможно, кому-то чем-то близка подобная тема — прошу поделиться пинком в нужном направлении.
как вариант — использование dll/com объектов дял работы с данными определенного формата.
приложение определяет версию документа, загружает объект который может этот документ прочитать
и создать внутреннее представление.
затем этот внутренний вид документа можно передать на другой объект для сохранения.
это позволяет разнести логику работы с версиями в отдельные объекты и не засорять основную логику приложения.
