Doctrine de l'Auditeur rapport de l'Abonné

Je travaille dans le framework Symfony2 et je me demandais quand allait-on utiliser une Doctrine de l'abonné par rapport à un auditeur. La Doctrine de l' la documentation pour les auditeurs est très clair, cependant, les abonnés sont plutôt passées sous silence. Symfony est livre de cuisine de l'entrée est similaire.

  • Ross Tuck avait un Doctrine2 parler sur le DutchPHPConference il y a quelques jours. Il traite également les événements dans Doctrine2, et ses slides sont ici: slideshare.net/rosstuck/... peut-être il pourrait y avoir quelques infos supplémentaires/aide pour vous.
  • Vous n'avez pas vraiment besoin d'auditeurs dans votre propre code. Voir Ne jamais utiliser des Écouteurs pour une réponse plus détaillée
InformationsquelleAutor nurikabe | 2012-05-24
  1. 86

    De mon point de vue, il y a seulement une différence majeure:

    • L'Auditeur est signé en précisant que les faits sur lesquels elle est à l'écoute.
    • L'Abonné dispose d'une méthode de raconter le répartiteur quels événements il est à l'écoute de

    Cela pourrait ne pas sembler une grosse différence, mais si vous pensez à ce sujet, il y a certains cas où vous souhaitez utiliser l'un sur l'autre:

    • Vous pouvez assigner un auditeur à beaucoup d'expéditeurs avec différents événements, tels qu'ils sont fixés au moment de l'enregistrement. Vous avez seulement besoin de s'assurer que chaque méthode est en place dans l'écouteur
    • Vous pouvez changer les événements d'un abonné est inscrit au moment de l'exécution, et même après l'enregistrement de l'abonné, en modifiant la valeur de retour de getSubscribedEvents (Pensez à un moment où l'on écoute une très bruyant événement et que vous souhaitez seulement à exécuter quelque chose une fois)

    Il pourrait y avoir d'autres différences que je ne suis pas au courant si!

    InformationsquelleAutor Sgoettschkes
  2. 9

    Ne sais pas si c'est fait accidentellement ou intentionnellement.. Mais les abonnés ont une priorité plus élevée que les auditeurs - https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L73-L98

    De la doctrine côté, il ne se soucie pas ce que c'est (auditeur ou de l'abonné), finalement les deux sont inscrits à titre d'auditeurs - https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/EventManager.php#L137-L140

    C'est ce que j'ai repéré.

    InformationsquelleAutor Ruslan Polutsygan
  3. 7

    Vous devez utiliser l'événement de l'abonné lorsque vous voulez traiter avec de multiples événements dans une classe, par exemple, dans ce symfony2 doc page de l'article, on peut constater que les écouteur d'événement ne peut gérer qu'un seul événement, mais disons que vous voulez traiter avec plusieurs événements pour une entité, prePersist, preUpdate, postPersist etc... si vous utilisez l'écouteur d'événement que vous auriez à code plusieurs écouteur d'événement, un pour chaque événement, mais si vous allez avec l'abonné, il suffit de coder une classe de l'événement susbcriber, look avec l'événement abonné, vous pouvez gérer plus d'un événement dans une classe, c'est bien la façon dont je l'utilise, j'préférez code concentré dans ce que le modèle d'affaires de besoin, un exemple de ce que peut être allé vous souhaitez gérer plusieurs événements de cycle de vie globalement uniquement pour un groupe d'entités, de faire ce que vous pouvez de code d'une classe parent et défini ces méthodes globales, alors faites de votre entités hériter de cette classe et, plus tard, dans votre cas susbcriber vous vous abonnez à chaque événement que vous souhaitez, prePersist, preUpdate, postPersist etc... et ensuite demander que les parents de la classe et de l'exécution de ces méthodes globales.

    • J'ai peut-être mal compris, mais dans mon expérience, un Auditeur peut gérer plusieurs événements, par exemple, un Auditeur peut définir des actions pour prePersist, preUpdate, onFlush, etc.
    • yup j'deuxième, " Cette auditeur peut écouter un ou plusieurs événements et est averti à chaque fois que ces événements sont distribués.' directement à partir de la documentation
    InformationsquelleAutor metalvarez
  4. 3

    Les deux vous permettent d'exécuter quelque chose sur un événement particulier pré /post persistent etc.

    Cependant d'auditeurs seulement vous permettent d'exécuter des comportements encapsulés au sein de votre Entité. Donc, un exemple pourrait être la mise à jour d'un "date_edited" timestamp.

    Si vous avez besoin de se déplacer à l'extérieur du contexte de votre Entité, vous aurez besoin d'un abonné. Un bon exemple peut être pour l'appel d'une API externe, ou si vous avez besoin d'utiliser /d'inspecter les données ne sont pas directement liées à votre Entité.

    • Je suis peut-être un malentendu, mais cela sonne comme la différence entre un cycle de vie de rappel et un écouteur d'événement? Je suis en train de déterminer quand je pourrais utiliser (dans Symfony2 termes) un doctrine.event_subscriber par opposition à doctrine.event_listener.
    InformationsquelleAutor Lee Davis
  5. 3

    Une autre chose importante: la Doctrine EventSubscribers ne vous permettent pas de définir une priorité.

    Lire davantage sur cette question ici

    • Ampoule continue. Merci!!!!
    InformationsquelleAutor Wilt
  6. 2

    Ici est ce que le doc a dit à ce sujet dans la section 4.1.
    Comme c'est appliquée dans le monde à des événements, je suppose que c'est aussi valable pour la Doctrine (pas sûr à 100%).

    Les auditeurs ou les Abonnés

    Les auditeurs et les abonnés peuvent être utilisés dans le même indistinctement. La décision d'utiliser l'un d'eux est généralement une question
    de goût personnel. Cependant, il existe quelques petits avantages pour chaque
    d'entre eux:

    • Les abonnés sont plus faciles à réutiliser car la connaissance des événements est conservé dans la classe plutôt que dans la définition du service.
      C'est
      la raison pourquoi Symfony utilise les abonnés à l'interne;
    • Les auditeurs sont plus souples car bundles pouvez activer ou désactiver chaque sous certaines conditions en fonction de la configuration de la valeur.

    http://symfony.com/doc/master/event_dispatcher.html#listeners-or-subscribers

    InformationsquelleAutor Kaizoku Gambare
  7. 0

    À partir de la documentation :

    La façon la plus commune pour écouter un évènement est d'enregistrer un événement
    écouteur avec le répartiteur. Cette auditeur peut écouter un ou plusieurs
    événements et est averti à chaque fois que ces événements sont distribués.

    Une autre façon d'écouter des évènements est via un événement d'abonné. Un événement
    l'abonné est une classe PHP qui est capable de dire le répartiteur exactement
    les événements qu'il souhaite s'inscrire. Il met en œuvre la
    EventSubscriberInterface de l'interface, ce qui nécessite un seul statique
    méthode appelée getSubscribedEvents().

    Voir l'exemple ici :

    https://symfony.com/doc/3.3/components/event_dispatcher.html

    InformationsquelleAutor Mohammed Yassine CHABLI