Anfrage in AKKA.NET

Question

Ich versuche die Query-Seite von CQRS in einer Katalog-Management-Anwendung mit AKKA.NET zu verstehen. Ich habe eine Benutzeroberfläche, die alle Produkte in einem Raster zeigen muss, das einem Kriterium folgt. Die Kriterien können sein Alle Produkte, die von Anbieter A kamen und dieses Kriterium wird in einem Formular auf der Benutzeroberfläche eingegeben.

Meine Frage ist, wie diese Abfrage durchgeführt wird? Wo soll ich die Abfrage ausführen? Soll ich alle Produktakteure in den Speicher laden, um die Abfrage auszuführen? Oder sollte ich in die hartnäckigen Medien gehen, in denen der Staat gerettet wird? Nachdem ich alle Produkt-IDs erhalten habe, die mit der Abfrage erfolgreich waren, sollte ich diese Produkt-IDs verwenden, um alle Akteure zu aktivieren?

Bitte beraten.

Answer 1

Ihre Frage klingt nicht wie streng Schauspieler bezogen, da es mehr CQRS vs CRUD Eigenschaft ist. Im Standard-CQRS-Szenario möchten Sie eine Art persistenten Speicher mit einem an Ihr Lesemodell angepassten Schema haben. Dann können Sie Ihre Abfragen darauf ausführen.

Eines der Dinge, die mir mit AkkA.NET in CQRS-basierten aber noch nicht Ereignis-Sourcing Szenario kommt, ist die Verwendung von Akka Event-Bus. Wenn Sie eine Anwendung starten, erstellen Sie Akteure, die für die Aktualisierung Ihres Lesemodells verantwortlich sind, und abonnieren Sie sie sofort für die akustischen Nachrichten, damit das Lesemodell aktualisiert werden muss. Dann veröffentlichen Sie in einem Akteur, der lesenseitige Änderungen hervorrufen kann, ein zugehöriges Ereignis/eine entsprechende Nachricht.

Wenn Sie Event Sourcing verwenden, würden Sie wahrscheinlich gerne einen Blick auf Akka.Peristence werfen. Dort haben Sie ein Konzept von Ereignisjournalen, das von sogenannten persistenten Schauspielern erstellt wurde. Es beschreibt den Strom aller Operationen, die von einem Akteur ausgeführt werden, der gespeichert werden sollte. Die zweite Sache ist eine andere Art von Akteur, die persistente Ansicht, die mit einem bestimmten Strom von Ereignissen assoziiert sein kann und ein Lesemodell von ihnen erzeugt. Während die persistente Sicht normalerweise mit einem einzelnen persistenten Aktor korreliert ist, können Sie Event Bus + Listeners erneut verwenden, um globale Lesemodelle zu erstellen. Einer der Vorteile dieses Ansatzes besteht darin, dass alle Ereignisse im permanenten Speicher gespeichert werden, wodurch Ihr System im Falle eines Ausfalls dauerhafter und einfacher wiederhergestellt werden kann.

Answer 2

Oder Sie könnten Ihr Denken auf den Kopf stellen und einen Akteur erstellen, der eine Abfrage darstellt. Wenn Sie die "Products" -Objekte abfragen, die nach allen Produkten von Anbieter A suchen, sendet jedes Product-Objekt Ihrem Abfrageaktor eine Aktualisierung seines aktuellen Status. Wenn dieser von Lieferant A bearbeitet wird, verarbeitet Ihr Abfrage-Actor das Objekt zu seiner Sammlung Ihr Abfrageschauspieler würde Objekte herausfiltern, die nicht in die Abfrageparameter passen. Jetzt haben Sie einen Actor, der eine Liste von Produkten enthält, die in Echtzeit aktualisiert werden, wenn neue Produkte erstellt, geändert usw.