Как использовать хранимые процедуры базы данных на mORMot?

#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.

Проверьте, например: