Здравствуйте, Аноним, Вы писали:

А>Коллеги,

А>Некоторое время не дает покоя тема версионности.
А>Допустим, тот же MS Word. От версии к версии формат документа меняется. И очень не хотелось бы, чтобы код "для обратной совместимости" рос пропорционально кол-ву версий, ибо: новый Office выходит раз в год-два. Если же продукт обновляется раз в квартал, то ой. Посему хотелось бы узнать, кто как борется с проблемой версионности данных без потери backward compatibility.

А>Как показало гугление на тему schema evolution, то основных подходов два: либо фиксировать версию данных при создании (т.е. аналогично интерфейсам — однажды объявленный, он не должен меняться, можно лишь объявлять новые интерфейсы), либо делать автообновление при открытии (путем user-defined кода).

А>Первый подход мне не нравится тем, что проблема версионности просто эскалируется в Data Access Layer, который должен содержать набор средств по унификации/преобразованию версий данных.
А>Второй подход не нравится именно "рукописностью" — простыня из методов FromV1ToV2, FromV2ToV3, FromV3ToV4 почему-то не воодушевляет

А>Возможно, кому-то чем-то близка подобная тема — прошу поделиться пинком в нужном направлении.

У нас применяется второй описанный Вами метод. То есть если какой-то компонент системы меняет свои структуры данных, то он же и поддерживает переход от старых структур к новым, то есть FromV1ToV2, FromV2ToV3, .... Тут V1, V2, ... это внутренние версии самих структур данных конкретного компонента (а не версии всего продукта).

А чем плох такой подход (я о втором варианте в целом)? ИМХО, это сродни Save As или Convert. Или они Вам тоже не нравятся?