Wie sollte ich meine Webanwendung am besten strukturieren, wenn ich Auftragswarteschlangen [und Perl/Catalyst] verwende?

Question

Ich schreibe eine Webanwendung unter Verwendung der Katalytischer Rahmen . Ich verwende auch eine Auftragswarteschlange namens DieSchwartz .

Ich möchte eine Auftragswarteschlange verwenden, weil ich möchte, dass ein Großteil des anwendungsspezifischen Codes vom Code der Webanwendungsschnittstelle entkoppelt wird.

Im Wesentlichen besteht das gesamte System aus drei Hauptkomponenten:

• GUI (Catalyst-Webschnittstelle)
• Ein Raupenfahrzeug
• Eine "Angriffskomponente" (die App wird geschrieben, um nach XSS- und SQLi-Schwachstellen in anderen Webapps/Sites zu suchen)

Theoretisch erzeugt die GUI also Aufträge für den Crawler, der wiederum Aufträge für die "angreifende Komponente" erzeugt.

Derzeit habe ich ein Modell in Catalyst, das ein TheSchwartz-Objekt instanziiert, damit die Controller in der Webanwendung Aufträge zur Auftragswarteschlange hinzufügen können.

Außerdem muss ich einige Job-Worker-Skripte erstellen, die kontinuierlich auf neue Aufträge warten (bzw. die Datenbank überprüfen), damit sie die erforderlichen Aktionen durchführen können. Derzeit befindet sich das DB-spezifische Material für TheSchwartz im Modell in Catalyst, und ich glaube nicht, dass ich darauf außerhalb von Catalyst leicht zugreifen kann.

Ich möchte die DB-Verbindungsdaten für die TheSchwartz-Warteschlange nicht im Modell und dann in meinen Jobworker-Skripten duplizieren. Sollte ich die Erstellung des TheSchwartz-Objekts in eine andere Klasse außerhalb von Catalyst verpacken und diese in dem Modell aufrufen, das gerade das TheSchwartz-Objekt instanziiert? Dann könnte ich das auch in den Arbeitsskripten verwenden. Oder sollte ich die DB-Daten in einer Konfigurationsdatei haben und neue TheSchwartz-Objekte instanziieren, wenn ich sie brauche (innerhalb von Catalyst/innerhalb der Worker-Skripte)?

Oder denke ich einfach zu viel darüber nach?

Einige Links zu ausführlichen Artikeln über die Architektur von Webanwendungen könnten ebenfalls nützlich sein (ich habe noch nie eine Anwendung von mittlerer Komplexität entwickelt).

Prost

Answer 1

Verwenden Sie DBIx::Class? Die Grundidee hier gilt auch, wenn Sie nicht sind, aber ich werde gehen und davon ausgehen, dass Sie sind.

Ein Catalyst-Modell sollte eine Umhüllung für eine andere Klasse sein, die gerade genug Verhalten bietet, um eine Schnittstelle zu Catalyst zu bilden, und sonst nichts. Zum Beispiel ist Catalyst::Model::DBIC::Schema nur eine Hülle für DBIx::Class::Schema. Sie holt sich die Konfiguration von Catalyst und übergibt sie an DBIC, sie injiziert die ResultSets in den Model-Namensraum (so dass Sie die $c->model('DB::Table') Trick), und dann wird er aus dem Weg geräumt.

Der Vorteil ist, dass der gesamte wichtige Code außerhalb von Catalyst::Model liegt und somit völlig unabhängig von Catalyst ist. Sie können Ihr Schema von einem Wartungsskript oder einem Jobqueue-Worker oder was auch immer laden, ihm eine Konfiguration übergeben, ihm sagen, dass es sich verbinden soll, und loslegen, ohne jemals Catalyst aufzurufen. Alle Informationen und die Logik, die in Ihren ResultSets und was auch immer enthalten ist, sind außerhalb von Catalyst genauso verfügbar wie innerhalb.

Answer 2

Wenn ich Sie richtig verstehe, lautet Ihre Frage: "Wie kann ich meine Datenbankverbindung außerhalb von Catalyst wiederverwenden?".

Sie sollten DBIx::Class in Ihrer Catalyst-Anwendung verwendet haben. Sie können die gleichen Dateien in jeder anderen Anwendung wiederverwenden. $c->mode('DB::MyTable')->search(...) in Catalyst ist dasselbe wie dieses außerhalb von Catalyst:

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

Jedes Modell kann außerhalb von Catalyst wie ein normales Paket MyApp::Model::Library->new() aufgerufen werden. Sie müssen nur sicherstellen, dass Sie $c nicht als Argument verwenden.

Answer 3

Sie sollten u. a. die Verwendung folgender Elemente in Betracht ziehen DerSchwartz::Einfach zur Erstellung von Aufträgen und nicht TheSchwartz selbst (den Sie eigentlich nur zur Bearbeitung von Aufträgen benötigen). Die Vorteile sind:

• Leichtgewichtig (es ist nicht nötig, den gesamten TheSchwartz in Ihre Catalyst-App zu laden)
• Akzeptiert ein einfaches Datenbank-Handle, um sich mit der Datenbank zu verbinden, während TheSchwartz im Wesentlichen eine eigene Datenbank-Wrapper-Schicht hat und möchte, dass Sie ihm Benutzernamen und Passwörter geben und seine eigene Verbindung verwalten (was Sie, wie Sie gesagt haben, nicht wollen)