(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0], j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src= 'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f); })(window,document,'script','dataLayer','GTM-5LHNRP9'); thecodest, Autor bei The Codest - Seite 7 von 9

Rubinrot auf Schiene (Rails, RoR) ist eine bekannte Web Anwendungsrahmenwerk, das in der Rubinrot Programmiersprache. Kneipe/Verleih ist eine Kurzbezeichnung für Software-Entwurfsmuster namens Veröffentlichen-Abbestellen. Ich werde erklären, wie die Kommunikation zwischen Softwarekomponenten in Rails mit Pub/Sub gehandhabt werden kann.

Was ist Pub/sub?

Kneipe/Verleih ist ein Software-Entwurfsmuster, das die Kommunikation von Dienst zu Dienst ermöglicht. Dienst
bringt eine der beiden Rollen mit sich: Herausgeber (der produziert) oder Empfänger (der konsumiert). Was ist
wird als Ereignis, Nachricht oder Meldung bestimmt. In der
Im Zusammenhang mit diesem Artikel werden beide Begriffe synonym verwendet und bezeichnen ein und dieselbe Sache.
Der Dienst, der produziert, weiß nicht, wer konsumiert. Der Dienst, der konsumiert, weiß nicht
den Ursprung der Nachricht kennen. Sie können sich gegenseitig unbekannt bleiben. Es ist anders als
Nachrichten-Warteschlangen, bei denen die Komponente, die die Nachricht sendet, oft das Ziel kennt
- Diese Art der Nachrichtenübermittlung ermöglicht es Ihnen, Nachrichten überall zu versenden. Dieser Mechanismus ist ein Kernstück
von Kneipe/Verleih und es bedeutet, dass sie entkoppelt sind.

Um ihre gegenseitigen Interessen zum Ausdruck zu bringen, müssen sie ein gemeinsames Verständnis haben. Deshalb,
beide Rollen haben einen impliziten Mechanismus des Sticks, bei dem der Produzent einer Nachricht und der
Verbraucher der Nachricht treffen. Dieser Mechanismus wird als Thema, Abonnement oder Topic bezeichnet. Er ist
der für die Zuordnung von Nachrichten zu Subjekten zuständig ist, handelt es sich im Wesentlichen um einen zustandslosen Nachrichtenfilter.
Themen fungieren als Sendestationen. Ein Herausgeber produziert die Nachricht für das Thema,
Die Abonnenten erhalten sofort die Nachricht des Themas. Aufgrund der entkoppelten
Diensten ist die effizienteste Art des Nachrichtenaustauschs die asynchrone Verarbeitung.

Rails ohne Pub/Sub

Standardmäßig gibt es in Rails keinen Overhead für Software-Entwurfsmuster zur Weitergabe von Nachrichten zwischen Komponenten. Entwickler verwenden Standard objektorientierte Programmierung (OOP) Paradigma: Übergabe von Parametern an Funktionen, Abfrage von Klassen über Werte.

Wenn die Anwendung eher unkompliziert ist, könnte dies ausreichen. Wenn die Anwendung wächst und beispielsweise einige Vorgänge asynchron ausgeführt werden müssen, dann muss die Projekt braucht Abstraktion, die das Problem löst Daten Arbeitsablauf. Anstatt das Rad neu zu erfinden, können Entwickler Kneipe/Verleih um diesen Mangel an Abstraktion auszugleichen.

Vorteile von Pub/Sub mit Rails

Nachteile von Pub/Sub mit Rails

Rails Pub/Sub einführen

Beispiele für Quellcode in Rails wurden mit der Bibliothek
Pub/Sub auf Rails (in der Nomenklatur von Ruby wird eine Bibliothek als gem bezeichnet): Weitere Details finden Sie in der Readme-Datei des Gems. Die Implementierung besteht aus Modulen:

  1. Bereich,
  2. Veranstaltung,
  3. Ereignisbehandler,
  4. Herausgeber der Veranstaltung,
  5. Abonnement.

Bereich

Beschreibt die Geschäftslogik, um den Kontext für Pub/Sub zu liefern und somit eine saubere Code.

 Modul Benachrichtigungen
   erweitern PubSub::Domain
 end
 Modul Berichte
   erweitern PubSub::Domain
 end

Veranstaltung

Es ist eine Klasse, die beschreibt, was passiert ist. Erklären Sie den Klassennamen so selbstbeschreibend wie möglich mit dem, was passiert ist, zum Beispiel: abgebrochen, geändert, erstellt, zerstört, gesendet, aktualisiert. Ereignisnamen können wie folgt aussehen: ProfitAndLossStatementCreatedEvent, was bedeutet, dass ein Finanzbericht erstellt wurde.

 class Reports::ProfitAndLossStatementCreatedEvent < PubSub::DomainEvent
   Attribut :gewinn_und_verlust_auszug_id, Typen::Strict::Integer
 end

Herausgeber der Veranstaltung

Klasse, die Ereignisse ausgeben kann. Das Beispiel zeigt die Erstellung eines Dienstberichts. Wenn der Bericht erfolgreich erstellt wurde, wird das Ereignis zur Erstellung des Berichts ausgegeben.

class Reports::ProfitAndLossStatementService
   include PubSub::Emit
    def ausführen
     emit(:report_gewinn_und_verlust_auszug_erstellt, gewinn_und_verlust_auszug_id: id) if result.ok?
   end
 end

Ereignis-Handler

Diese Klasse sollte als Reaktion auf die Behandlung eines Ereignisses ausgeführt werden.

Modul Benachrichtigungen
 class ReportsProfitAndLossStatementCreatedHandler < PubSub::DomainEventHandler
   def call
     ReportMailer.gewinn_und_verlust_auszug(gewinn_und_verlust_auszug).deliver_now
   end

   private

   def gewinn_und_verlust_aussage
     Gewinn-und-Verlust-Rechnung.find(event_data.gewinn-und-verlust-Rechnung_id)
   end
 end
end

Abonnement

Ereignisse sind durch Abonnements an ihre Bearbeiter gebunden.

Benachrichtigungen:
 reports__profit_and_loss_statement_created: async

Beispielhafte Anwendungsfälle:

Ähnliche Muster

  1. EreignisBus - Komponenten können Ereignisse an EventBus senden, ohne zu wissen, wer sie abholen wird oder wie viele Teilnehmer sie haben werden. reagieren,
  2. Beobachter - Das Subjekt unterhält eine Liste von abhängigen Personen, den so genannten Beobachtern, und benachrichtigt diese, sobald sich ihr Zustand ändert,
  3. Pooling - Beim Polling fragen die Clients das System regelmäßig, ob es neue Ereignisse oder Daten gibt.

Edelsteine

Zusammenfassung

Pub/sub ist kein üblicher Ansatz in Ruby in Rails. Wie im Artikel vorgestellt, kann dieses Muster viele Vorteile für das Projekt bringen - es kann den Code sauber machen, Dienste entkoppeln und sie leicht skalierbar machen.

Kooperationsbanner
de_DEGerman