Существует комплекс, написанный на Clipper-е, старенький, но поддерживаемый.
Планируем осуществить постепенный переход на платформу Delphi-Interbase, с
преобразованием структуры данных.
Но не мгновенный, не хватает ресурсов, а постепенный, постепенно написать
к существующим базам программы заменяющие clipper-овские программы, а когда будет
полностью заменены все программы произвести переход на interbase. Далее
последует преобразование структуры данных.
Думаю применить 4-х слойную архитектуру.
1- слой платформенно зависимый (для Delphi это TTable и TQuery)
2- слой структурно зависимый осуществляет преобразование текущей структуры
в конечную структуру
3- слой бизнес логики — соответствует новой структуре таблиц.
4- Интерфейс пользователя.
Переход тогда будет осуществлятся следующим образом
1) пишется 4 слоя
2) изменяется 1 слой ни interbase
3) изменяется 2 слой под до итоговой структуры и в итоге представляет тонкую прослойку
Выскажите свои мысли и критику.
У меня сомнения по поводу выделения 2-го слоя, может стоит объединить с 3?
K>Переход тогда будет осуществлятся следующим образом K>1) пишется 4 слоя K>2) изменяется 1 слой ни interbase K>3) изменяется 2 слой под до итоговой структуры и в итоге представляет тонкую прослойку
K>Выскажите свои мысли и критику.
Плохая идея.
1) Будет затрачено лишнее время на
а) достижение абстракции
б) на написание двух слоев — для клиппера и для interbase, для клиппера в конечном итоге слой окажется нунежным
2) на отладку глюков обоих слоев и совместимости с существующим софтом
3) конечное приложение будет спроектировано в угоду файл-серверной работе без учетов особенной клиент-серверной архитектуры, и в связи с этим оптимальным не будет
Поэтому я лично считаю что единственным правильным выходом из данной ситуации будет
1) проектирование БД для Interbase совершенно абстрагируясь от структуры хранения данных в Clipper и руководствуясь исключительно функциональностью софта
2) написание утилиты конвертации clipperной БД в новую БД Interbase
3) обучение пользователей новой версии на тестовой БД с попутным использованием их в качестве тестеров
4) переход пользователей на новую версию
Здравствуйте, ku032pai, Вы писали:
K>Существует комплекс, написанный на Clipper-е, старенький, но поддерживаемый. K>Планируем осуществить постепенный переход на платформу Delphi-Interbase, с K>преобразованием структуры данных.
Чем вызвана необходимость использовать именно Delphi-Interbase?
Здравствуйте, ku032pai, Вы писали:
K>Существует комплекс, написанный на Clipper-е, старенький, но поддерживаемый. K>Планируем осуществить постепенный переход на платформу Delphi-Interbase, с K>преобразованием структуры данных.
Имхо, несколько неудачный выбор. Особенно в свете того, что Борланд стремится от нее отделаться (продать).
Спасибо за ответ.
_>Плохая идея. _>1) Будет затрачено лишнее время на _> а) достижение абстракции _> б) на написание двух слоев — для клиппера и для interbase, для клиппера в конечном итоге слой окажется нунежным _>2) на отладку глюков обоих слоев и совместимости с существующим софтом _>3) конечное приложение будет спроектировано в угоду файл-серверной работе без учетов особенной клиент-серверной архитектуры, и в связи с этим оптимальным не будет
Да здесь вы правы, но есть некоторые обстоятельства которые я не уточнил.
1) Парк машин очень разнообразный, имеются 486 машины с терминальной загрузкой.
2) Организация бюджетная, т.е. имеет возможность покупать по 5-10 машин за квартал, полная замена парка произойдет
примерно через года два.
3) Комплекс состоит из десятка программ, полноценно поддерживать которые на Clippere возможности нет, если ввод данных — сильно не меняется, то отчетная часть меняется постоянно и довольно сильно.
_>Поэтому я лично считаю что единственным правильным выходом из данной ситуации будет _>1) проектирование БД для Interbase совершенно абстрагируясь от структуры хранения данных в Clipper и руководствуясь _>исключительно функциональностью софта _>2) написание утилиты конвертации clipperной БД в новую БД Interbase _>3) обучение пользователей новой версии на тестовой БД с попутным использованием их в качестве тестеров _>4) переход пользователей на новую версию
Здесь вы тоже полностью правы, но ввиду описанных обстоятельств, мгновенная замена комплекса представляется сложной.
Здравствуйте, DeZhavi, Вы писали:
DZ>Здравствуйте, ku032pai, Вы писали:
K>>Существует комплекс, написанный на Clipper-е, старенький, но поддерживаемый. K>>Планируем осуществить постепенный переход на платформу Delphi-Interbase, с K>>преобразованием структуры данных. DZ>Чем вызвана необходимость использовать именно Delphi-Interbase?
Delphi — наличием кадров.
Interbase — Окончательно не выбрано, пока как вариант. Какие есть предложения?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, ku032pai, Вы писали:
K>>Существует комплекс, написанный на Clipper-е, старенький, но поддерживаемый. K>>Планируем осуществить постепенный переход на платформу Delphi-Interbase, с K>>преобразованием структуры данных.
L>Имхо, несколько неудачный выбор. Особенно в свете того, что Борланд стремится от нее отделаться (продать).
Delphi — наличие сотрудников.
Interbase — ??, предложите альтернативу.
