Utilisation de l’event dispatcher depuis les classes du modèle.


Olivier
Utilisation de l’event dispatcher...

Le but de cet article n’est pas d’expliquer le fonctionnement des événements symfony, la documentation officielle est très bien faite à ce sujet, et pas mal d’articles expliquant leur implementation existent déjà.

Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.

(suite…)

Show Comments (4)

Comments

  • NiKo

    Y’a quand même de drôle de problème avec la coloration syntaxique du code dans ce billet, dommage :/

    Sinon ravi d’avoir aidé/inspiré 🙂

    • Article Author
  • Samuel Breton

    Les couleurs sont maintenant ok. Je sais pas qui avait tout pété..

    • Article Author
  • Khepin

    Je suis retourné voir la doc vu qu’il me semblait qu’il y avait un moyen simple d’accéder à l’event dispatcher depuis absolument partout, et ce qu’ils disent c’est:

    $dispatcher = ProjectConfiguration::getActive()->getEventDispatcher();
    permet de récupérer l’event dispatcher depuis n’importe où dans l’application.

    Moi j’ai commencé à utiliser les évènements récemment, ma réaction serait plutôt, « mais pourquoi on n’a pas ça direct en standard dans le langage? ». Plutôt côté accros donc!

    • Article Author
  • Éric Rogé

    Avec ce système, vous mixez au sein du même projet le système d’événements de Doctrine et celui de Symfony.

    Je suis bien placé pour savoir que ça peut provoquer de mauvaises surprises. J’ai utilisé cette technique sur un projet qui lançait/écoutait un grand nombre d’événements (https://freelancer-app.fr) et je m’en suis mordu les doigts.

    Certains événements dépendaient du système de Doctrine et d’autres de celui de symfony. Je ne savais parfois plus qui lançait/écoutait quoi. Sur certains événements complexes, j’ai finis par me retrouver avec des problèmes liés à l’ordre d’appel des listeners et de synchronisation des objets en mémoire.

    J’ai presque fini à un refactoring en profondeur de mon projet, la quasi-totalité de mes événements sont gérés par doctrine.
    Je trouve que l’organisation du code s’en trouve bien mieux et qu’elle est au final plus logique: tous les événements qui modifient un composant du modèle sont gérés par les événements de Doctrine dont c’est quand même le boulot.

    Les quelques événements symfony restants sont très marginaux, comme par exemple des alertes emails qui ne modifient pas en retour le modèle.

    • Article Author

Recevez nos articles