#delphi #stored-procedures #firebird #mormot
#delphi #хранимые процедуры #firebird #mormot
Вопрос:
Я реализую приложение с использованием mORMot с Delphi из существующего клиент-серверного приложения, которое использует базу данных Firebird с множеством хранимых процедур, связанных с обновлением некоторых таблиц и запросом очень сложных данных. Переопределение и перемещение всего из базы данных на сторону приложения заняло бы слишком много времени.
Я понятия не имею, что делать. Кто-нибудь, пожалуйста, помогите мне узнать, как использовать хранимые процедуры Firebird — call в mORMot. (Было бы здорово, если бы был пример.)
Комментарии:
1. Его документация предполагает, что это возможно (см. Главу 13), но в ней очень мало деталей.
2. Тогда почему mORMot? Если вы используете традиционный дизайн базы данных, отличный от ORM, то, возможно, другие библиотеки, традиционные клиент-серверные, будут иметь больше смысла? Унифицированные Interbase, FireDAC, DB Express, FIB (коммерческие и, казалось бы, мертвые), IBObjects и т.д.
mORMot
имеет свой собственный очень строгий взгляд на то, как система (программа и база данных) должна быть спроектирована и должна работать. Использование mORMot для другого подхода создало бы огромный пробел, который вам пришлось бы преодолеть. Так что, если вы не собираетесь реструктурировать саму базу данных — я считаю, что mORMot был бы неправильным выбором здесь3. @Arioch’The mORMot — это не просто ORM. Он имеет очень мощный уровень SOA, основанный на интерфейсах, который отлично подходит для создания надежных клиент-серверных приложений. Вы можете использовать уровень SOA без ORM и существующий уровень доступа к данным SQL с огромной выгодой. Вам не нужно писать полный проект DDD. Просто определите сервисы, используя интерфейсы и классы, с минимальным кодированием (намного меньше, чем, например, DataSnap). Смотрите мой ответ ниже. И последняя ссылка, в частности.
Ответ №1:
Хранимые процедуры отлично подходят для прямого доступа к базе данных, но они являются кошмаром для современного дизайна. Таким образом, в mORMot нет прямого / встроенного способа запуска хранимых процедур, потому что это не имеет смысла при проектировании ORM и современной архитектуре SOA / микросервисов / DDD.
Что вы могли бы сделать с mORMot и вашим существующим проектом, например:
-
Создайте первый уровень повторно используемых сервисов «бизнес / модель», используя несколько интерфейсов — ваш собственный «logic toolbox»;
-
Пусть классы реализации этих интерфейсов вызывают существующие хранимые процедуры, используя существующую библиотеку FireBird access;
-
Опубликуйте службы уровня «бизнес / модель», используя другой набор общедоступных конечных точек REST, используя сервисы на основе интерфейса mORMot и расширенные интерфейсы REST с помощью простых DTO;
-
Пусть новые формы вашего клиентского приложения переключаются с RAD на этот n-уровневый дизайн / REST, вызывая эти новые сервисы на основе интерфейса mORMot, если это возможно;
-
Подумайте о написании какого-нибудь нового клиентского кода, возможно, из клиента JavaScript REST / JSON (для этого вы можете использовать стороннюю компанию);
-
Взгляните на mORMot Web MVC layer — php-подобную функцию фреймворка, которая может помочь в написании некоторых динамических веб-страниц из вашего существующего уровня «бизнес / модель»;
-
Рассмотрите возможность использования mORMot
ORM
для новых таблиц и новых данных, возможно, переключившись на микросервисную архитектуру с собственным уровнем сохраняемости SQLite3 (или все же Firebird вам действительно нужен, но вы можете переключиться с помощью ORM); -
Преимущества для множества сквозных функций фреймворка, таких как ведение журнала, обработка pdf или JSON.
Взгляните на часто задаваемые вопросы по документации и задайте вопрос на форуме mORMot / Synopse.
Проверьте, например: