2014-06-08 17 views
10

Ich bin gerade dabei, eine ziemlich große Akka-basierte Java-Anwendung zu erstellen, und ich stoße auf ein paar Probleme, die mich zu keinem Ende bringen.Namenskonventionen für Akka-Nachrichten und -Aktoren

Mein aktuelles Paket Layout sieht irgendwie wie folgen aus:

Project Structure

Meine Mobile Klasse, die als Supervisor der Akteure innerhalb des actors Pakets dient.

Da will ich nicht einen neuen Satz von Schauspielern jeden HttpClient und Account, denn ich die um in Botschaftsobjekten passieren schaffen, die in den Nachrichten Paket gespeichert sind, zusammen mit dem Endpunkt ActorRef, die das Endergebnis erhält. Dies erzeugt jedoch ein sehr überfülltes messages-Paket mit einer anderen Nachricht für jeden Akteur. Z.B. MobileForActor1, Actor1ForMobile, MobileForActor2 usw. Nun meine Frage ist, gibt es eine Konvention für diese Art von Sachen zu verwenden, die sich mit diesem Problem beschäftigt und ist meine Struktur (Mobile ->Actor1 ->Mobile ->Actor2. -> usw.), um die Art und Weise Akka will es sein, oder muss ich nur die Nachrichten Wasserfall (Mobile ->Actor1 ->Actor2 -> etc.)

Im Moment bin ich ein ConnectMessage meiner Mobile Schauspieler zu senden, die dann zu Actor1 sendet, es Actor1 Prozesse und sendet eine neue Nachricht zurück an Mobile sendet Mobile diese Antwort dann auf Actor2 und der Zyklus geht weiter mit einer neuen Nachricht basierend auf der alten Nachricht erstellt werden. Z.B. new Message2(message1.foo, message1.bar, message1.baz, newComputatedResult, newComputatedResult2, etc);

Ist diese gute Praxis oder sollte ich die alte Instanz (die möglicherweise Informationen enthält, die nicht mehr nützlich sind) und die neuen Sachen einbeziehen? Z.B. new Message2(message1, newComputatedResult, newComputatedResult2, etc);

Oder sollte ich etwas komplett anderes machen?

Ich dachte über TypedActors, aber diese erfordern die Verwendung eines Wasserfallmusters und ich weiß nicht, wie ich den ActorRef des Zuhörers weiterleiten würde, der das Endergebnis erhalten möchte.

Ich hoffe, ich habe mich verständlich genug gemacht, weil Englisch nicht meine ersten Sprachen ist und dass die Frage jedem klar ist.

Ich bin ein Anfänger Akka Entwickler und liebe die Idee, aber da die Dokumentation dies nicht sehr gut abdeckt, dachte ich, dies wäre der beste Ort, um zu fragen. Danke fürs Lesen!

Antwort

7

Ich werde einige Kommentare als Antwort darauf wagen, weil ich mich mit den gleichen Problemen in meiner Lernkurve von Akka befasst habe. Ich denke, du fragst nach einigen Faustregeln, damit meine hier enthalten sind.

Erstens ist die Schaffung von Schauspielern unglaublich billig; Sie sind sehr leicht. Also, warum nicht für jeden HttpClient und Account einen erstellen und ihnen geeignete Namen geben, die von ihrer Identität abgeleitet sind? Dadurch vermeiden Sie auch, dass Sie sie wahrscheinlich so viel weitergeben müssen, dass Sie Ihren Code entschlüsseln.

Zweitens, halten Sie Ihre Nachrichtennamen kurz, fokussiert und beginnen mit einem Verb. Jede Nachricht sollte dem Schauspieler sagen, dass er etwas tun soll, also soll der Name das durch ein Verb wiedergeben.

Drittens gehen Sätze von Nachrichten mit dem Schauspieler.Normalerweise deklariere ich sie im Companion-Objekt der Aktor-Klasse, so dass sie wie ActorClass.MessageName verwendet wird, es sei denn, es ist innerhalb ActorClass und dann ist es nur MessageName.

Viertens fügen Sie einen Zähler an den Namen eines Schauspielers an. Ich kombiniere oft einfach einen Zähler (AtomicInteger) mit dem Namen des Typs (Car-1, Car-2, etc.).

Wenn die Hierarchie für Sie wichtig ist, würde ich empfehlen, nur den übergeordneten Akteur an den Namen anzuhängen. Etwas wie Phone-1-in-Car-7, das Phone-1 bedeutet, ist in Car-7 enthalten. Sie können die Hierarchie dann programmatisch und manuell zusammenstellen, indem Sie den übergeordneten Links folgen.

Ich denke, "Message" in ConnectMessage ist redundant. Machen Sie einfach den Namen der Nachricht "Connect" oder noch besser "ConnectToThing" (was immer das ist, wenn das relevant ist).

Ich würde Ihre Nachricht Namen nicht zu viel wie Sie mit Message2 vorschlagen. Verwenden Sie die minimale Menge an Informationen, um für diejenigen nützlich zu sein, die diese Namen lesen werden. Ich denke, dass die fehlende Antwort darauf aus diesem Teil Ihrer Frage resultieren könnte. Ich fand es verwirrend, da viele Details fehlen.

Hoffe, das hilft.

+0

Können Sie einige Beispiele für eine gute Benennung von Nachrichten zeigen? Zum Beispiel habe ich einen Lieferanten und einen Verbraucher. Der Verbraucher möchte den Lieferanten fragen, wie viele Waren er hat. Wie würden Sie Nachrichten für Anfrage und Antwort benennen? –

+0

@TemaBolshakov - Wie wäre es mit "GetGoodsCountRequest" und "GetGoodsCountResponse"? –

+0

nicht sicher diese Namen idiomatisch genug in scala. Ich mag den ersten, aber der spätere sieht ein bisschen überflüssig aus. Vielleicht ist es besser, mit Int zu antworten? Oder definieren Sie einen Typalias für Int, zum Beispiel 'type GoodsCount = Int '. Was ist die beste Option in Scala? –