2012-05-24 10 views
57

Estoy trabajando en el marco de Symfony2 y me pregunto cuándo se usaría un suscriptor de Doctrine versus un oyente. Doctrine's documentation para oyentes es muy claro, sin embargo, los suscriptores se pasan por alto. Symfony's cookbook entry es similar.Oyente de Doctrina versus Suscriptor

+0

Ross Meta tenía una Doctrine2 hablar sobre el DutchPHPConference hace unos días. También trató los eventos en Doctrine2, y sus diapositivas están aquí: http://www.slideshare.net/rosstuck/extending-doctrine-2-for-your-domain-model-13257781 tal vez podría ser algo de información extra/ayuda para ti. –

Respuesta

66

Desde mi punto de vista, sólo hay una diferencia importante:

  • El oyente se inscribió especifica los eventos en el que escucha.
  • El suscriptor tiene un método diciendo que el despachador qué eventos se está escuchando a

Esto podría no parecer una gran diferencia, pero si se piensa en ello, hay algunos casos en los que desea utilizar uno sobre el otro:

  • Puede asignar un oyente a muchos despachadores con diferentes eventos, ya que están configurados en el momento del registro. Solo necesita asegurarse de que todos los métodos estén en su lugar en el oyente
  • Puede cambiar los eventos en los que se registra un suscriptor en tiempo de ejecución e incluso después de registrar el suscriptor cambiando el valor de retorno de getSubscribedEvents (piense en un momento en el que escucha a un evento muy ruidoso y solo quiere ejecutar algo una vez)

¡Sin embargo, podría haber otras diferencias que no conozco!

+16

Entonces, en pocas palabras, ¿un suscriptor es un oyente donde la lista de eventos monitoreados es mutable? En 'getSubscribedEvents', entonces devolvería una matriz, algo así como' array (Events :: prePersist, Events :: postUpdate) '¿Supongo? – nurikabe

+5

Sí. Eche un vistazo aquí: http://docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/reference/events.html#the-event-system – Sgoettschkes

5

Ambas le permiten ejecutar algo en un evento en particular pre/post persisten etc.

Sin embargo oyentes sólo le permiten ejecutar comportamientos encapsulados dentro de su Entidad. Así que un ejemplo podría ser actualizar una marca de tiempo "date_edited".

Si necesita mudarse fuera del contexto de su Entidad, necesitará un suscriptor. Un buen ejemplo podría ser llamar a una API externa, o si necesita utilizar/inspeccionar datos que no están directamente relacionados con su Entidad.

+5

Podría estar malinterpretando, pero esto suena como la diferencia entre una devolución de llamada de ciclo de vida y un oyente de evento? Estoy tratando de determinar cuándo podría usar (en términos de Symfony2) un 'doctrine.event_subscriber' en lugar de' doctrine.event_listener'. – nurikabe

+0

Tienes razón, leí tu pregunta, disculpas. –

7

Debe utilizar el suscriptor de eventos cuando desee tratar múltiples eventos en una clase, por ejemplo en este symfony2 doc page article, se puede notar que el oyente de eventos solo puede administrar un evento, pero digamos que desea tratar varios eventos para una entidad, prePersist, preUpdate, postPersist, etc. ... si usa el detector de eventos, debe codificar varios escuchas de eventos, uno para cada evento, pero si va con el suscriptor de eventos, solo tiene que codificar una clase, el suscriptor de eventos, mirar que con el suscriptor del evento puede administrar más de un evento en una clase, así es como lo uso, prefiero el código enfocado en lo que necesita la empresa modelo, un ejemplo de esto puede ser que quiera manejar varios eventos del ciclo de vida globaly solo para un grupo de tus entidades, para hacer eso puedes codificar una clase padre y definir los métodos globales en ella, y luego Nuestras entidades heredan esa clase y más tarde en el evento suscriptor, usted se suscribe a cada evento que desee, prePersist, preUpdate, postPersist, etc. ... y luego solicite esa clase principal y ejecute esos métodos globales.

+3

Puede que le haya malinterpretado, pero en mi la experiencia de un oyente puede gestionar múltiples eventos, por ejemplo un oyente puede definir acciones para prePersist, preUpdate, onFlush, etc. –

+0

@ChadwickMeyer yup i que 'este oyente puede escuchar uno o más eventos y se le notifica cada vez que se envían esos eventos.' directamente desde el documento – Dheeraj

8

no sabe si se hace accidental o intencionalmente .. Pero los suscriptores tienen mayor prioridad que los oyentes - https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L73-L98

Desde el lado doctrina, no le importa lo que es (oyente o abonado), con el tiempo, tanto están registrados como oyentes - https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/EventManager.php#L137-L140

Esto es lo que vi.

2

Otra cosa importante: Doctrine EventSubscribers no le permite establecer una prioridad.

leer más sobre este tema here

+0

La bombilla continúa. ¡Gracias! – nurikabe