L'auditeur de la doctrine par rapport à l'abonné

Question

Je travaille dans le cadre de Symfony2 et je me demande quand utiliser un abonné Doctrine plutôt qu'un écouteur. La méthode de Doctrine documentation pour les auditeurs est très clair, mais les abonnés sont plutôt négligés. L'interface de Symfony entrée du livre de recettes est similaire.

Answer 1

De mon point de vue, il n'y a qu'une seule différence majeure :

• Le Listener est inscrit en spécifiant les événements sur lesquels il écoute.
• L'abonné possède une méthode indiquant au distributeur les événements qu'il écoute.

La différence peut sembler minime, mais si l'on y réfléchit bien, il existe des cas où il est préférable d'utiliser l'un plutôt que l'autre :

• Vous pouvez affecter un auditeur à plusieurs répartiteurs avec des événements différents, car ils sont définis au moment de l'enregistrement. Vous devez seulement vous assurer que chaque méthode est en place dans le listener.
• Vous pouvez modifier les événements pour lesquels un abonné est enregistré au moment de l'exécution et même après l'enregistrement de l'abonné en modifiant la valeur de retour de la fonction getSubscribedEvents (Pensez à un moment où vous écoutez un événement très bruyant et où vous ne voulez exécuter quelque chose qu'une seule fois).

Il y a peut-être d'autres différences dont je ne suis pas conscient !

Answer 2

Je 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

Du côté de la doctrine, peu importe ce qu'elle est (auditeur ou abonné), les deux sont finalement enregistrés en tant qu'auditeurs. https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/EventManager.php#L137-L140

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

Answer 3

Vous devriez utiliser l'abonné d'événement quand vous voulez traiter plusieurs événements dans une classe, par exemple dans cette symfony2 doc page article Si vous utilisez l'écouteur d'événements, vous devrez coder plusieurs écouteurs d'événements, un pour chaque événement, mais si vous optez pour l'abonné d'événements, vous n'aurez à coder qu'une seule classe. si vous utilisez l'écouteur d'événements, vous devrez coder plusieurs écouteurs d'événements, un pour chaque événement, mais si vous optez pour l'abonné d'événements, vous n'aurez qu'à coder une classe, l'abonné d'événements, regardez qu'avec l'abonné d'événements, vous pouvez gérer plus d'un événement dans une classe, et bien c'est la façon dont je l'utilise, je préfère coder en fonction de ce que le modèle d'affaires a besoin, un exemple de ceci peut être que vous voulez gérer plusieurs événements de cycle de vie globalement seulement pour un groupe de vos entités, pour faire cela vous pouvez coder une classe parent et définir ces méthodes globales en elle, puis faire que vos entités héritent de cette classe et plus tard dans votre susbcriber d'événement vous souscrivez chaque événement que vous voulez, prePersist, preUpdate, postPersist etc. ... puis vous demandez cette classe parente et exécutez ces méthodes globales.

Answer 4

Autre chose importante : les EventSubscribers de Doctrine ne vous permettent pas de définir une priorité.

Plus d'informations sur ce sujet aquí

Answer 5

Voici ce que dit la doc à ce sujet en 4.1. Comme cela s'applique globalement aux événements, je suppose que c'est également valable pour Doctrine (pas sûr à 100%).

Auditeurs ou abonnés

Les écouteurs et les abonnés peuvent être utilisés indistinctement dans la même application. La décision d'utiliser l'un ou l'autre est généralement une question de goût personnel. Cependant, il existe quelques avantages mineurs pour chacun d'entre eux :

• Les abonnés sont plus faciles à réutiliser car la connaissance des événements est conservée dans la classe plutôt que dans la définition du service. C'est raison pour laquelle Symfony utilise les abonnés en interne ;
• Les écouteurs sont plus flexibles car les paquets peuvent activer ou désactiver chacun d'entre eux de manière conditionnelle en fonction d'une valeur de configuration.

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