Ich begann mit dem Actor-Modell und insbesondere mit Akka.NET . Insgesamt denke ich, dass ich eine gute Vorstellung davon habe, was genau ist, aber natürlich steckt der Teufel im Detail. Ich habe darüber nachgedacht, Akka.NET in eine bereits bestehende Codebasis zu übernehmen, und daher möchte ich abschätzen, wie viele der vorhandenen Abstraktionen beibehalten werden können. Die Idee ist, dass einige spezifische High-Level-Schnittstellen beibehalten werden können, und einige Adapter-Implementierungen würden geschrieben werden, um nahtlos zwischen der Welt der Aktoren und den Benutzern der vorhandenen Schnittstellen hin- und herzugehen, aber ich bin mir nicht sicher, ob das empfohlen wird und was Arten von spezifischen Problemen, mit denen ich rechnen sollte.
Triviales Beispiel:
%Vor% In diesem Fall stammt die IGetSet -Schnittstelle von der traditionellen Welt , und ihre Implementierung lässt uns mit der Darstellerwelt hin und her wechseln. Ich habe versucht, mit Schauspielern nett zu sein, die nie anders als Nachrichtenübergabe verwendet werden, so dass diese (triviale, natürlich) Übung insgesamt vielversprechend aussieht, aber ich würde gerne wissen, ob es noch etwas gibt, auf das ich seit dem Tag achten sollte 1.
Ich habe gelesen, dass wir zusätzliche nicht-akteursbasierte asynchrone Codes vermeiden, die Schließungen von Akteuren einbeziehen, das ist klar und ich mache das nicht, aber vielleicht gibt es noch mehr, die ich nicht sehen kann. Mein letztes Ziel ist es, dieses Muster ziemlich umfassend zu verwenden, bis hinunter zu Punkt würde ich Schauspieler-orientierte Implementierungen von Rx ISubject schreiben (was ich schon getan habe und es war einfach, aber ich bin mir nicht sicher, ob ich genug darauf geachtet habe alles was ich sollte).
Ich lese auch etwas über getippte Schauspieler , aber ich bin es kein Scala-Experte, also werde ich vielleicht nicht alle Details aus den Code-Beispielen verstehen und bin mir nicht sicher, ob sie bereits in Akka.NET verfügbar sind ( Doc-Seite ist ein 404 )
Das sieht gut aus. Was Sie berücksichtigen sollten, ist, dass die Darsteller standardmäßig eine Liefergarantie von "höchstens einmal" haben. Berücksichtigen Sie daher bei der Kommunikation mit Ihrem Darsteller, dass Sie möglicherweise keine Antwort erhalten . (Netzwerkfehler, abgestürzte entfernte Knoten und so)
In einem lokalen System ist es sehr unwahrscheinlich, dass eine Nachricht verloren geht, aber in der Theorie könnte das Akteurs-System abstürzen, wenn jemand etwas zu wild damit macht und somit die Schauspieler sterben.
Wenn Sie also mit einem Akteur kommunizieren, der Ask verwendet, seien Sie besser sicher und geben Sie eine Zeitüberschreitung ein und behandeln Sie diese Ausnahme anstelle von block / wait für immer.
Async / Await wird ab den neuesten Pre-Release-Bits (vor 1.0) unterstützt.
Es ist jedoch nicht der empfohlene Ansatz. besser bei PipeTo bleiben und explizit sein.
Eine weitere Sache, die zweifelhaft werden könnte, ist, dass Sie in Ihrem Beispiel den Schauspieler als einen Schlüsselwert-Laden behandeln, was alles in Ordnung ist.
Und deine Botschaften sind auch unveränderlich, was auch gut ist.
Wenn jedoch die Schlüssel- oder Werteigenschaften ref-Typen sind und Leute diese von außen mutieren können, z. die Konsumenten von IGetSet , die RC-Probleme innerhalb des Akteurs verursachen könnten, da der Akteur diese Werte lesen könnte, wenn ein anderer Thread sie mutiert.
ActorSystems sind auch ziemlich teuer, versuchen zu vermeiden, dass viele Systeme hochgefahren werden, streben nach einem System pro Prozess.
Abgesehen davon, Sie sind gut zu gehen.
Tags und Links c# actor system.reactive akka.net