Come dovrei strutturare al meglio la mia applicazione Web usando le code dei lavori [e Perl / Catalyst]?

Question

Sto scrivendo un'applicazione Web utilizzando il Catalyst framework . Sto anche usando una coda di lavoro chiamata TheSchwartz .

Voglio utilizzare una coda lavori perché desidero che una parte del codice specifico dell'applicazione sia stata disaccoppiata dal codice dell'interfaccia dell'applicazione Web.

Fondamentalmente l'intero sistema è costituito da tre componenti principali:

• GUI (Catalyst web interface)
• Un cingolato
• Un componente "attaccante" (l'app è stata scritta per cercare le vulnerabilità XSS e SQLi in altri siti / app Web)

Quindi, in teoria, la GUI crea lavori per il crawler che a sua volta crea lavori per il "componente attaccante".

Attualmente ho un modello in Catalyst che crea un'istanza di un oggetto TheSchwartz in modo che i controller nell'app Web possano aggiungere lavori alla coda dei lavori.

Devo anche creare alcuni script per i lavoratori che ascoltano continuamente (/ controllano il database) per nuovi lavori in modo che possano eseguire le azioni richieste. Attualmente le cose specifiche del DB per TheSchwartz sono nel Modello in Catalyst e non penso di potervi accedere facilmente al di fuori di Catalyst?

Non voglio duplicare i dati di connessione al DB per la coda dei lavori di TheSchwartz nel Modello e poi nei miei script di lavoro. Dovrei concludere la creazione dell'oggetto TheSchwartz in un'altra classe seduta fuori da Catalyst e chiamarla nel Modello che sta attualmente istanziando l'oggetto TheSchwartz? Quindi potrei anche usarlo negli script di lavoro. O dovrei avere i dati DB in un file di configurazione e creare un'istanza di nuovi oggetti TheSchwartz come e quando ne ho bisogno (all'interno di Catalyst / all'interno degli script di lavoro)?

O sto solo pensando a questo?

Alcuni collegamenti ad articoli di architettura di app Web carnosi possono anche essere utili (non ne ho mai costruito uno di moderata complessità prima ..).

Saluti

Answer 1

Stai usando DBIx :: Class? L'idea di base qui si applica anche se non lo sei, ma vado avanti e presumo che tu lo sia.

Un modello Catalyst dovrebbe essere un wrapper per un'altra classe, fornendo il comportamento sufficiente per interfacciarsi con Catalyst e nient'altro. Ad esempio Catalyst :: Model :: DBIC :: Schema è solo un wrapper per DBIx :: Class :: Schema. Ottiene la configurazione da Catalyst e la passa a DBIC, inietta i ResultSet nello spazio dei nomi del Modello (in modo da poter eseguire il trucco $ c- > model ('DB :: Table') ) e poi si fa da parte.

Il vantaggio è che poiché tutto il codice importante vive al di fuori di Catalyst :: Model, è completamente indipendente da Catalyst. Puoi caricare il tuo Schema da uno script di manutenzione o da un lavoratore del jobqueue o qualsiasi altra cosa, passarlo un po 'di configurazione, dirgli di connettersi e andare, senza mai invocare Catalyst. Tutte le informazioni e la logica presenti nei set di risultati e qualsiasi altra cosa sia ugualmente disponibile all'esterno di Catalyst come all'interno.

Answer 2

Se ho capito bene, la tua domanda è " come posso riutilizzare la mia connessione al database al di fuori di Catalyst? " ;.

Dovresti aver usato DBIx :: Class nella tua applicazione Catalyst. Puoi riutilizzare gli stessi file in qualsiasi altra applicazione. $ c- > mode ('DB :: MyTable') - > search (...) in Catalyst è uguale a questo al di fuori di catalyst:

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

Qualsiasi modello può essere chiamato al di fuori di Catalyst come un normale pacchetto MyApp :: Model :: Library- > new (). Vuoi solo assicurarti di non usare $ c come argomento.

Answer 3

Una delle cose che dovresti dare un'occhiata è usare TheSchwartz :: Simple per creare lavori anziché TheSchwartz stesso (di cui hai davvero bisogno solo per elaborare i lavori). I vantaggi sono:

• Leggero (non è necessario caricare l'intero TheSchwartz nella tua app Catalyst)
• Accetta un semplice handle di database per connettersi al database, mentre TheSchwartz ha essenzialmente il proprio layer wrapper di database e vorrà che tu gli dia nomi utente e password e gestisca la propria connessione (che hai detto che non lo vuoi) da fare)