Je me suis amusé à Scala pendant un certain temps, et j'ai étudié Akka de loin, et je suis finalement plongé dedans. Le trait FSM a scellé l'affaire pour moi. Ce qui me préoccupe, c'est que j'ai peut-être conçu la façon dont les données seraient partagées de manière inappropriée, et j'ai peut-être mal conçu la boucle de traitement des événements pour correspondre aux meilleures pratiques d'Akka.Akka, Thread Dispatchers, Agents Best Practice
Dans mon problème, j'ai un coordinateur central qui va faire correspondre les demandes de tâches entrantes aux acteurs appropriés qui sont également des machines à états finis. J'avais initialement supposé que onTransition donnerait non seulement le nom d'état mais aussi les données d'état. Je suppose que l'encapsulation traditionnelle des données serait la raison de ne pas exposer ces données aux auditeurs. Mais pour moi, j'ai deux utilisations pour les autres de voir ces données.
Les données d'état contiennent un objet de domaine sous-jacent dont les propriétés sont utilisées pour déterminer quels acteurs sont les meilleurs candidats pour gérer le travail en fonction de ses besoins. Comme les exigences professionnelles sont dynamiques, j'hésite à avoir des collections séparées d'acteurs travailleurs (même si je ne suis pas sûr de savoir pourquoi cela devrait me faire réfléchir).
L'idée d'interroger tous les acteurs séparés qui rencontrent d'autres conditions préalables et de se joindre à toutes leurs réponses semble inefficace ou du moins pas idiomatique pour Akka. Je vais également devoir afficher dans l'interface utilisateur l'état actuel et ne voir aucune raison qui devrait utiliser la même file d'attente pour afficher l'état. Quoi qu'il en soit, je considérais la mise à jour FSM comme un agent, mais puisque c'est un acteur lui-même, je ne suis pas sûr de ce que cette couche d'indirection m'achète et cela peut rendre le raisonnement sur la séquence des événements beaucoup plus difficile.
La Collaboration d'événements de Fowler me permet d'envoyer les données d'état de manière explicite, mais j'espérais pouvoir le faire plus facilement pour toutes les transitions qui mettent à jour automatiquement les données d'état. J'ai aussi beaucoup de mal à comprendre le séquençage des cascades d'événements, et si j'ai besoin de contrôler cela. Même si tous mes événements externes entrants proviennent d'un seul acteur, je veux traiter tous les événements générés en interne à tous les autres acteurs avant de gérer le prochain événement externe. Je pensais utiliser le coordinateur central !! pour attendre une réponse, mais je crains que si je supprime accidentellement un point d'exclamation quelque part dans la chaîne de l'événement que je vais perdre cette garantie. Solutions Je considère ce problème comme l'utilisation d'événements prioritaires de sorte que les événements internes reçoivent une priorité plus élevée, en utilisant un répartiteur à thread unique (peut-être avec work voler?) Pour tous les acteurs "internes" partagés.
Y a-t-il des pratiques exemplaires pour ce que j'essaie de faire, ou est-ce que j'essaie de faire la mauvaise chose :)?