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

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

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

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

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

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

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

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

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

Или я просто слишком много думаю об этом?

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

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


architecture web-applications catalyst perl job-queue
person Adam Taylor    schedule 25.10.2009    source источник

Ответы (3)


arrow_upward
4
arrow_downward

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

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

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

person hobbs    schedule 26.10.2009

arrow_upward
3
arrow_downward

Если я правильно понимаю, ваш вопрос: «Как я могу повторно использовать мое соединение с базой данных вне 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 в качестве аргумента.

person Julien    schedule 26.10.2009
comment
Многие модели не будут работать, если вы сделаете это. Он оставляет класс приложения пустым, а конфигурацию неинициализированной и не вызывает ACCEPT_CONTEXT, поэтому модели, написанные в соответствии с рекомендуемым шаблоном адаптера, на самом деле вообще не будут работать. - person hobbs; 26.10.2009

arrow_upward
3
arrow_downward

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

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