Создание модульных приложений с помощью OverPLAY
Приложения, использующие библиотеку OverPLAY, могут быть разбиты на несколько частей. Первая часть представляет собой обычно исполняемый файл, управляющий загрузкой модулей, обменом информацией между ними и предоставляющий пользователю возможность обратиться к тому или иному модулю. Остальные части представляют собой модули, выполненные в виде динамически загружаемых библиотек.
При создании многофункционального приложения с использованием OverPLAY следует спланировать разделение функций приложения между модулями, учитывая зависимость между ними - зависящие друг от друга функции имеет смысл поместить в один модуль.
Создание модульного приложения обычно начинается с создания исполняемого файла, главная форма которого содержит компонент TAppServer. При создании исполняемого файла обычно следует предусмотреть управляющие элементы, которые будут использоваться для обращения к задачам из дополнительно загружаемых модулей (например, кнопки, недоступные до момента загрузки и регистрации модуля).
Рис. 2. Главная форма исполняемого файла, использующего компоненты OverPLAY
Далее следует создать дополнительно загружаемые модули - DLL. Такой модуль должен содержать скрытую форму, на которой должен быть помещен компонент TDLLServer, и в секции инициализации библиотеки следует присвоить имя этой формы глобальной переменной OverPlayMainForm (библиотека поставляется с нескольким примерами различной степени сложности, где можно найти образцы соответствующего кода, и весьма подробной справкой, содержащей, помимо общепринятого в таких случаях описания классов и компонентов, советы по созданию модульных приложений).
Рис. 3. Скрытая форма дополнительно загружаемого модуля
При запуске исполняемого файла пользователь может загрузить и зарегистрировать необходимые библиотеки. После этого задачи из этих библиотек станут также доступны для регистрации и дальнейшего использования.
Рис. 4. Приложение, использующее дополнительно загружаемые модули, на этапе выполнения
Рис. 5. Список зарегистрированных дополнительных модулей и содержащихся в них задач
Отметим, что при желании можно организовать использование задачами общих ресурсов, например, соединений с базой данных (соответствующий пример, содержащий также динамически загружаемые библиотеки с отчетами, есть в комплекте поставки библиотеки).
Конечно, идея создания модульных приложений не нова. В частности, использование технологии COM, предназначенной в первую очередь для создания приложений, использующих другие приложения и библиотеки в качестве поставщиков тех или иных сервисов, также позволяет создать модульное многофункциональное приложение. Однако взаимодействие COM-серверов и клиентов предполагает маршалинг (обмен пакетами данных) с помощью вызовов удаленных процедур (даже при условии присутствия сервера и клиента на одном компьютере), что, с одной стороны, позволяет иметь одну и ту же модель программирования независимо от того, внутренним, локальным или удаленным является COM-сервер, а, с другой стороны, вынуждает расплачиваться за эту общность более низкой производительностью и ограничениями на используемые типы данных. Поэтому построение модульного приложения из нескольких взаимодействующих друг с другом DLL в случае, когда используемые сервисы не предполагается запускать удаленно, и следовательно, маршалинг и вызов удаленных процедур не требуются, оправдано как с точки зрения производительности, так и с точки зрения упрощения процесса разработки приложений.
