Как мне лучше всего структурировать свое веб-приложение, используя очереди заданий [и Perl/Catalyst]?

Question

Я пишу веб-приложение, используя Платформа катализатора.Я также использую очередь заданий под названием Шварц.

Я хочу использовать очередь заданий, потому что хочу, чтобы большая часть кода приложения была отделена от кода интерфейса веб-приложения.

По сути вся система состоит из трех основных компонентов:

• Графический интерфейс (веб-интерфейс Catalyst)
• Гусеничный робот
• «Атакующий компонент» (приложение пишется для поиска уязвимостей XSS и SQLi в других веб-приложениях/сайтах).

Таким образом, теоретически графический интерфейс создает задания для сканера, который, в свою очередь, создает задания для «атакующего компонента».

В настоящее время у меня есть модель в Catalyst, которая создает экземпляр объекта TheSchwartz, чтобы контроллеры в веб-приложении могли добавлять задания в очередь заданий.

Мне также нужно создать несколько сценариев рабочих заданий, которые постоянно прослушивают (/проверяют базу данных) на наличие новых заданий, чтобы они могли выполнять необходимые действия.В настоящее время конкретные материалы БД для TheSchwartz находятся в модели в Catalyst, и я не думаю, что смогу легко получить к ним доступ за пределами Catalyst?

Я не хочу дублировать данные подключения к БД для очереди заданий TheSchwartz в модели, а затем в сценариях моих рабочих заданий.Должен ли я обернуть создание объекта TheSchwartz в другой класс, находящийся за пределами Catalyst, и вызвать его в модели, которая в данный момент создает экземпляр объекта TheSchwartz?Тогда я мог бы также использовать это в рабочих сценариях.Или мне следует хранить данные БД в файле конфигурации и создавать экземпляры новых объектов TheSchwartz по мере необходимости (внутри Catalyst/внутри рабочих сценариев)?

Или я просто об этом подумал?

Некоторые ссылки на содержательные статьи об архитектуре веб-приложений также могут быть полезны (раньше я никогда не создавал ничего средней сложности...).

Ваше здоровье

Answer 1

Вы используете DBIx::Class?Основная идея здесь применима, даже если это не так, но я собираюсь предположить, что это так.

Модель Catalyst должна быть оболочкой для другого класса, обеспечивающей достаточное поведение для взаимодействия с Catalyst и ничего больше.Например, Catalyst::Model::DBIC::Schema — это просто оболочка для DBIx::Class::Schema.Он получает конфигурацию от Catalyst и передает ее в DBIC, а затем вводит наборы результатов в пространство имен модели (чтобы вы могли выполнить $c->model('DB::Table') трюк), а затем он уходит с дороги.

Преимущество состоит в том, что, поскольку весь важный код находится за пределами Catalyst::Model, он полностью независим от Catalyst.Вы можете загрузить свою схему из сценария обслуживания, работника очереди заданий или чего-то еще, передать ей некоторую конфигурацию, приказать ей подключиться и работать, даже не вызывая Catalyst.Вся информация и логика в ваших наборах результатов и все остальное в равной степени доступны как вне Catalyst, так и внутри.

Answer 2

Если я правильно понимаю, ваш вопрос: «Как можно повторно использовать подключение к базе данных за пределами Catalyst?».

Вы должны были использовать DBIx::Class в своем приложении Catalyst.Вы можете повторно использовать те же файлы в любом другом приложении. $c->mode('DB::MyTable')->search(...) в Catalyst то же самое, что и вне катализатора:

my $schema = MyApp::Model::DB->new();
$schema->resultset('MyTable')->search(...)

Любую модель можно вызвать вне Catalyst, как обычный пакет MyApp::Model::Library->new().Вам просто нужно убедиться, что вы не используете $c в качестве аргумента.

Answer 3

Одна из вещей, на которую вам следует обратить внимание, это использование Шварц::Простой для создания рабочих мест, а не сам TheSchwartz (который вам действительно нужен только для обработки заданий).Преимущества:

• Легкий вес (нет необходимости загружать весь TheSchwartz в приложение Catalyst)
• Принимает простой дескриптор базы данных для подключения к базе данных, тогда как TheSchwartz, по сути, имеет собственный уровень оболочки базы данных и хочет, чтобы вы давали ему имена пользователей и пароли и управляли собственным соединением (чего, как вы сказали, вы не хотите)