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

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

7 голосов
/ 26 октября 2009

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

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

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

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

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

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

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

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

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

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

Приветствия

Ответы [ 3 ]

4 голосов
/ 26 октября 2009

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

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

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

3 голосов
/ 26 октября 2009

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

2 голосов
/ 27 октября 2009

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

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