LazWeb: автоматический старт модуля

[mike]

Существует ли культурный способ сделать так, чтобы мой экземпляр TFPWebModule создавался сразу на старте приложения, а не после прилета первого запроса от клиента?
Пока вижу только адский костыль в виде ручного вызова HandleRequest при первом срабатывании OnIdle.

Добавлено спустя 2 часа 37 минут 12 секунд:

Пока вижу только адский костыль в виде ручного вызова HandleRequest при первом срабатывании OnIdle.

Блин, OnIdle тоже не срабатывает до первого запроса к приложению...

[WAYFARER]

Так и задумано. TFPWebModule создаётся по запросу. Экземпляры модулей изначально рассчитаны на короткую жизнь и контекст запроса, поэтому культурного способа создать его раньше (и держать) не предусмотрено.
Есть только некультурные способы, которые являются потенциально опасными.
На вскидку :
1. Технически TFPWebModule это TComponent, его можно Create(nil), но это будет в обход фабрики, со всеми вытекающими.
2. Чуть более адекватный способ отправить запрос из приложения (например TFPHTTPClient) после старта сервера, но до Application.run. А еще лучше сделать запрос из отдельного потока, тогда он с гарантией отработает.

Но, если честно, мне в голову не приходит ни одной причины так делать. Для чего это нужно?

Добавлено спустя 6 минут 36 секунд:
Если нужно выполнить какую то подготовительную работу перед первым запросом то лучше сделать так

Код: Выделить всё

unit Preloader;

interface
procedure Preload;

procedure Preload;
begin
  //грузим/делаем что нужно.
end;

initialization
  Preload; // выполнится при запуске приложения
end.

т.е. просто делаем отдельный юнит/класс и подключаем его в любом месте проекта.

[mike]

Это нужно для того, чтобы приложение начинало выполнять свою работу вне зависимости от того, что там будет (и будет ли) с клиентскими запросами.
Раз TFPWebModule -- наследник TDataModule, то я и использовал его как дата-модуль, разместив на нем всю "фоновую" логику для работы с БД, которая по идее должна начинать работать сразу.

[WAYFARER]

TFPWebModule -- наследник TDataModule

Скорее всего это и сбило вас с толку. То что он наследник TDataModule не делает его Model. Наследование здесь чисто технический выбор, TDataModule = удобный контейнер для компонентов.
Но роль в архитектуре задаёт не предок, а поведение - HandleRequest, маршруты, Request/Response.

то я и использовал его как дата-модуль, разместив на нем всю "фоновую" логику для работы с БД, которая по идее должна начинать работать сразу.

Это так не работает. Вернее работает, но это в корне не правильно. TFPWebModule суть есть контроллер, прослойка между HTTP-контекстом и вашей бизнес-логикой.
TFPWebModule парсит вход, вызывает нужный сервис и формирует ответ, а бизнес-логика живёт в своих юнитах/классах к которым модуль обращается.
Правильная архитектура выглядит примерно так (упрощенно):
1. Первый слой Services, это по факту бизнес-логика, он ничего не знает про HTTP/Request/Response.
2. Data Access, работа с данными, возвращает Data Transfer Object(не TRequest!!!)
3. Transport, TFPWebModule - парсит вход, вызывает сервис, формирует ответ.

[mike]

Да, я уже переделал.
На TFPWebModule оставил то, что должно существовать только в контексте соответствующего web-сервиса, и может быть высвобождено в любой момент.
Все остальное перенес в отдельный обычный TDataModule, который создается классическим методом Application.CreateForm(TDM, DM) и существует все время жизни процесса.