Вопрос по doctrine-orm, symfony – Слушатель Доктрины против Подписчика

70

Я работаю в среде Symfony2 и задаюсь вопросом, когда можно было бы использовать подписчика Doctrine вместо слушателя. Учение & APOS; sдокументация для слушателей это очень понятно, однако подписчики довольно мрачны. Symfony & APOS; sзапись поваренной книги похож.

Несколько дней назад Росс Так провел лекцию по Doctrine2 на конференции DutchPHPConference. Он также рассмотрел события в Doctrine2, и его слайды находятся здесь:slideshare.net/rosstuck/… Может быть, это может быть дополнительная информация / помощь для вас. Kees Schepers

Ваш Ответ

7   ответов
8

сделано ли это случайно или намеренно. Но подписчики имеют более высокий приоритет, чем слушатели.https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/DependencyInjection/CompilerPass/RegisterEventListenersAndSubscribersPass.php#L73-L98

Со стороны доктрины, его не волнует, кто он (слушатель или подписчик), в конечном итоге оба регистрируются как слушатели -https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/EventManager.php#L137-L140

Это то, что я заметил.

7

когда вы хотите иметь дело с несколькими событиями в одном классе, например, в этомsymfony2 страница документа docМожно заметить, что прослушиватель событий может управлять только одним событием, но допустим, что вы хотите работать с несколькими событиями для одной сущности: prePersist, preUpdate, postPersist и т. д. Если вы используете обработчик событий, вам придется кодировать несколько прослушивателей событий, по одному на каждое событие, но если вы идете с подписчиком на событие, вам просто нужно кодировать один класс на событие-подписчик, посмотрите, что с подписчиком на событие вы можете управлять более чем одним событием в одном классе, и вот как я его использую, я предпочитаю чтобы код был сфокусирован на том, что нужно модельному бизнесу, можно привести один пример: вы хотите обрабатывать несколько глобальных событий жизненного цикла только для группы ваших сущностей, чтобы сделать это, вы можете закодировать родительский класс и определить в нем эти глобальные методы, затем заставьте ваши сущности наследовать этот класс, а затем в вашем получателе событий вы подписываетесь на каждое желаемое событие, prePersist, preUpdate, postPersist и т. д., а затем запрашиваете этот родительский класс и выполняете эти глобальные методы.

Возможно, я вас неправильно понял, но по моему опыту слушатель может управлять несколькими событиями, например, один прослушиватель может определять действия для prePersist, preUpdate, onFlush и т. д.
@ChadwickMeyer Да, во-вторых, этот «слушатель может прослушивать одно или несколько событий и получает уведомление каждый раз, когда эти события отправляются». прямо из документов
0

The most common way to listen to an event is to register an event listener with the dispatcher. This listener can listen to one or more events and is notified each time those events are dispatched.

Another way to listen to events is via an event subscriber. An event subscriber is a PHP class that's able to tell the dispatcher exactly which events it should subscribe to. It implements the EventSubscriberInterface interface, which requires a single static method called getSubscribedEvents().

Смотрите пример здесь:

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

83

The Listener is signed up specifying the events on which it listens. The Subscriber has a method telling the dispatcher what events it is listening to

Это может показаться не большой разницей, но если вы подумаете об этом, есть некоторые случаи, когда вы хотите использовать один поверх другого:

You can assign one listener to many dispatchers with different events, as they are set at registration time. You only need to make sure every method is in place in the listener You can change the events a subscriber is registered for at runtime and even after registering the subscriber by changing the return value of getSubscribedEvents (Think about a time where you listen to a very noisy event and you only want to execute something one time)

Могут быть и другие различия, о которых я не знаю!

Да. Посмотрите здесь:docs.doctrine-project.org/projects/doctrine-orm/en/2.0.x/…
ссылка в посте @Sgoettschkes не работает, ток вроде должен бытьdoctrine-project.org/projects/doctrine-orm/en/latest/reference/…
Итак, в двух словах, подписчик является слушателем, где список отслеживаемых событий является изменчивым? ВgetSubscribedEvents Я бы тогда возвращал массив, что-то вродеarray(Events::prePersist, Events::postUpdate) Похоже? nurikabe
3

и другое позволяет вам выполнить что-то на определенном событии до / после сохранения и т. Д.

Однако слушатели позволяют вам только выполнять поведение, инкапсулированное в вашей сущности. Таким образом, примером может быть обновление & quot; date_edited & quot; метка времени.

Если вам нужно выйти за пределы контекста вашей организации, вам понадобится подписчик. Хорошим примером может быть вызов внешнего API или если вам нужно использовать / проверять данные, не связанные напрямую с вашей организацией.

Ваше право, я неправильно понял ваш вопрос, извинения.
Возможно, я неправильно понимаю, но это звучит как разница между обратным вызовом жизненного цикла и прослушивателем событий? Я пытаюсь определить, когда я могу использовать (в терминах Symfony2)doctrine.event_subscriber в отличие отdoctrine.event_listener. nurikabe
3

подписчики Doctrine не позволяют вам устанавливать приоритет.

Подробнее об этом выпускеВот

Лампочка горит. Спасибо! nurikabe
2

Поскольку это применимо к событиям во всем мире, я полагаю, что это также верно для Доктрины (не уверен на 100%).

Listeners or Subscribers

Listeners and subscribers can be used in the same application indistinctly. The decision to use either of them is usually a matter of personal taste. However, there are some minor advantages for each of them:

Subscribers are easier to reuse because the knowledge of the events is kept in the class rather than in the service definition. This is the reason why Symfony uses subscribers internally; Listeners are more flexible because bundles can enable or disable each of them conditionally depending on some configuration value.

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

Похожие вопросы