Benennung von Listenern in Symfony2

Question

Ich habe einige Anleitungen/Tutorials über Symfonys Event System gelesen. Aber ich bin mir immer noch nicht sicher über die Benennung Best Practice. Leider verwenden die meisten Dokumentationen Standardszenarien wie Login, usw. Hier ist ein Beispiel aus einem Spiel:

Ein Befehl bewertet eine Art von Übereinstimmungsergebnis. Sie feuert ein entsprechendes Ereignis wie folgt aus:

$dispatcher->dispatch('game_bundle.match_won', new MatchWonEvent($match, $winner)); 

Jetzt habe ich mehrere Zuhörer zu behandeln dieses Ereignis, wie zum Beispiel einer für dieses Posting auf dem Siegerfacebook-Seite und ein weiteres Buch einen Erfolg für den Gewinner registrieren möchten. In den Beispielen habe ich festgestellt, dass der Listener, der das Login-Ereignis behandelt, hauptsächlich als etwas wie LoginListener bezeichnet wurde, aber sollte sich dieser Name nicht auf die tatsächliche Verwendung beziehen, anstatt auf das Ereignis, auf das er bezogen ist? Weil ich jetzt in meinem Beispiel eine MatchWonListener benötige, aber sollte diese sowohl die Facebook- als auch die Leistungslogik enthalten? Das würde das Ereignissystem dann nutzlos machen ... Wäre es nicht besser, einen FacebookListener mit einem onMatchWon($event) und einen AchievementListener mit seiner eigenen onMatchWon($event) Methode zu haben? Dies würde es auch leicht machen, mehr Facebook-bezogene Ereignisse in die FacebookListener zum Beispiel hinzuzufügen.

Ich bin verwirrt über die Benennung in den Proben und nicht sicher über jetzt. Habe ich es total falsch verstanden?

Answer 1

Es gibt kein "Best Practice" zum Benennen von Ereignissen. Wenn Sie jedoch den Listener nach dem Ereignis benennen, wird der Zweck der Ereignisse nach meinem Dafürhalten komplett zunichte gemacht. Das Ziel besteht darin, verschiedene Teile Ihres Systems miteinander interagieren zu lassen, ohne Probleme zu lösen und zu mischen.

Also, wenn man bedenkt, dass Sie so weit gegangen sind, Ereignisse zu erstellen, um Probleme zu trennen, warum sollten Sie dann alle verschiedenen Logiken in einen Listener mischen? In diesem Fall können Sie auch einfach einen direkten Anruf tätigen, anstatt ein Ereignis zu versenden.

Ich bin persönlich gegen Namen wie "onMatchWon", weil das nicht beschreibt, was die Methode tut. Angenommen, Sie möchten ein gewonnenes Event hören und die Erfolge des Benutzers, der gewonnen hat, aktualisieren. Ich hätte wahrscheinlich einen Benutzer-Manager-Dienst oder die Sortierung mit einer Methode updateAchievements(MatchWonEvent $event). Aber ich denke, das ist eher Geschmackssache oder Konvention, wenn Sie dazu bereit sind.