Консервативная модернизация системы

Ситуация несколько абстрактная, по совокупности нескольких.

Допустим, имеется достаточно старая система еще с борланд-паскальными кусками, ООП практически не используется, местами с обработкой строк в сишном стиле, BDE + ODBC, простыни спагетти-кода, где прикладная логика размазана по событиям. Несколько "ортодоксальная" реализация с прямыми запросами к СУБД (MS SQL), хотя имеется небольшое количество хранимых процедур. В общем, стандартный набор "прелестей". Предпоследняя среда разработки Delphi 4, перенесена в 2006 или 2007, на очереди 2009.

Обьем кода (порядка 500К-1М строк) и функционала (сотни модулей и функций) достаточно велик, чтобы забыть о "переписывании нахрен". База данных относительно компактная (единицы сотен таблиц) и небольшая по обьему (единицы гигабайт), тип использования - транзакционный и аналитический. Структуры спроектированы неплохо, однако практически отсутствует поддержка целостности на уровне СУБД.

Отчеты (сотни форм) - локально, типа crystal reports через ODBC.

Функциональная архитектура (декомпозиция, номенклатура задач, раширяемость на существующей базе и т.д.) в целом хорошего качества.

Ресурсы у разработки минимальные - команда порядка 5-7 человек включая функциональных спецов и тестеров. Бета-тесты делают ключевые пользователи/клиенты. Во время разработки требуется минимальная поддержка текущей версии.

Цели модернизации:
- снижение затрат на внесение изменений (в основном косметика, функционально система сложилась и будет меняться слабо)
- облегчение развертывания (единицы сотен АРМ), в идеале - один EXE, который можно копировать или запускать с веб-странички, автообновление версий
- реструктуризация технической архитектуры: декомпозиция монолита, обозримость, ясность, снижение "хрупкости" (меняем в одном месте, появляется аномалия в другом)
- разделение логики с другими приложениями, например, веб-клиент для некоторых функций (для простоты считаем, что они также разрабатываются на Delphi)

Возможные варианты:
- постепенный вынос логики на уровень СУБД, реструктуризация интерфейса по MVC (model-view-controller), "тонкий" веб-сервис для доступа к слою логики
или
- вынос логики в модули даных, затем - на сервер приложений, доступ через веб-сервисы, реструктуризация интерфейса MVC
далее
- отчеты - миграция на MS SQL Server Reporting Services
- организация полноценной подсистемы метаданных (по ним генерируем часть кода)
- еще что-то...

Чтобы не утонуть в деталях, вначале хотелось бы послушать начальника транспортного цеха, например, что "было принято решение по выносу логики в модули данных, затем их вынесли на сервер и стали использовать удаленно (midas, еще что-то в т.ч. свое). Это дало преимущества в том-то, решило следующие проблемы, но еще остались такие-то проблемы и появились новые". Прежде всего интересуют мнения имевших реальный опыт подобной модернизации

P.S. Разумеется, BDE не годится по многим критериям. Использование веб-служб существенно упрощает работу в глобальной сети, для сохранения DataSet-подхода потребуется реализация своих на основе ClientDataSet, например. Вынос отчетов на сервер (SSRS) также решает многие проблемы развертывания. ООП в базе данных необходимо в разумных пределах, минимально - сокрытие доступа к таблицам на уровне ХП и проекций, CRUD-часть генерируется по метаданным (если они есть), реестр обьектов, ядро безопасности. Тонкий веб-сервис в данном варианте только вызывает нужную ХП и возвращает результат, по сути обертка протокола работы с сервером приложений (реализованном в виде слоя ХП). Ну ладно, это детали.

P.P.S. Новая реализация DataSnap в Delphi 2009 также кажется хорошим вариантом модернизации. См. The New DataSnap in Delphi 2009

Forums: 

Имеем нечто

Имеем нечто похоже. D7. Свыше тысячи пользователей и тиражные продукты на 4 платформах СУБД. Более 10 лет жизни. Свой фреймворк упрошает жизнь. С BDE перешли на DBExpress. Для работы в 3-звенке тестируем сейчас свой драйвер над HTTP под веб-службами, не требующий, практически никакой переделки 10 летних залежей кода. Логика в основном на клиенте, проблем с этим не испытывается. Остальное различие требует мелкоскопа.

Изображение пользователя Serguei_Tarassov.

Хорошее решение

Хорошее решение. В вашем варианте возможны несколько шагов:
- отказ от BDE (здесь необходимо сохранить функции TUpdateSQL, т.к. логика CRUD непростая, поэтому DBExpress неочевиден, или вы свои аналоги писали?)
- прозрачно перевести транспорт под веб-сервис
- частями выносить логику на сервер или в СУБД (у вас, как я понял, задача подключения новых приложений и разделения ими общей логики не стоит)

1. Там 10 спецов

1. Там 10 спецов смотрело, DbExpress и ничего другого.
2. А тут я 5 лет спеца искал который бы взялся эту прозрачность обеспечить.
3. Она решается разделением метабазы между приложениями. Логика на сервере удорожает поддержку многоплатформенности, существенных плюсов для себя не нашли.

Изображение пользователя Serguei_Tarassov.

DbExpress etc

1. Удалось ли "малой кровью" перенести "тонны" ;) TUpdateSQL?
2. Знакомая картина
3. Согласен, усложняет при реализации на уровне СУБД, да и на уровне СП тоже, если его требуется портировать под какой-нибудь линукс, что в наши дни не исключено. Как всегда есть свои плюсы и минусы.

А что имеется в виду под "разделением метабазы между приложениями"? Подсистема метаданных, доступная всем через некоторый простой API?

Пришлите

Пришлите запрос. Я дам ссылку на технологию. Не вижу смысла дальше вести публичную переписку, которая мало кого, кроме нас интересует.

Изображение пользователя Serguei_Tarassov.

Спасибо

Спасибо, воспользуюсь вашим предложением

Ну почему же неинтересно

Ну почему же неинтересно? Мы сидели, внимательно слушали, высказывались в параллельном топике на sql.ru, с которого нас сюда и заманили - а теперь в приватную беседу? АбиднА тА кАк...

Если Вам

Если Вам интересна наша ситуация и принимаемые решения, пишите письмо. Кто-то любит публично, кто-то приватно, у нас, однако, свобода в данном выборе.

а вот и мне тоже

а вот и мне тоже интересно, хотя проект поменьше, но решаю похожую задачу, тоже интересны мысли тех, кто уже прошёл этой дорогой. оч жаль, что вы таки перешли в приват

А чем Вам

А чем Вам претит приват ? Опишите свою ситуацию письмом. Получите ссылки и комментарии. Вам информация важна или стриптиз на публике ?

Изображение пользователя Serguei_Tarassov.

А вы не теряйтесь

А вы не теряйтесь, высказывайте свои вопросы и мысли. Совместно что-нибудь придумаем.

Изображение пользователя ipanshin.

Страна советов

Страна советов окончилась, но совет, как начальник транспортного цеха, могу дать. Как известно уже, в моем транспортном цеху был опыт реанимации биллинговой системы BillonLine, клиенты которой был написаны на foxPro, а сервер жил на ms sql. Я, не останавливая работу старой системы, откомпилировал туда весь кернел нексуса и далее параллельно сопровождая старую систему, начал писать новый функционал, получая, естественно, удовольствие.
Правда, тебе придется выкинуть клиента нексуса версии 247 и перейти на мою версию 252, где написан некоторый инструментарий по автогенерации классов нексуса. Скорость такого инструментария примерно 1 простой класс за 30 минут. Есть правда некоторыое ограничение. Автогенерация не может создавать таблицы иерархические. Я этого не дописал тогда.
Внедрение нового клиента началось сразу же после первого просмотра в отделе обслуживания клиентов после пары месяцев моей работы. Девочки с удовольствием начали работать на двух клиентах сразу. Старом и новом.
На самом деле этим опытом я горжусь так как, если бы все рухнуло, то я до сих пор тарифицировал бы звонки вместо биллинговой системы.