Question

修改：为避免混淆，此问题与Entity Listener和无关于 Event Listener

有关

我正在学习Symfony事件，并研究EntityListeners和EventSubscribers的工作方式。

据我所知，EntityListener只附加到一个实体，而所有实体都调用了EventSubscriber方法。最终在EventSubscriber类中我必须做这样的事情：

public function prePersist(LifecycleEventArgs $args)
{
    $object = $args->getObject();

    if ($object instanceof xxxxxxx) {
        $this->doSomething();
    }
}

所以看来每当我需要监听单个实体的事件时，我应该使用EntityListener，当我想要监听所有Doctrine实体的事件时，我应该使用EventSubscriber。

但是......看看最受欢迎的捆绑包，如FOSUserBundle，VichUploaderBundle，SonataMediaBundle等，它们都使用EventSubscriber接口，但没有一个使用EntityListener。即使他们只需要听一个实体。

我还没有看到一个可以使用EntityListener的包。

我的问题是：为什么？

从我的角度来看，EntityListener应该更高效，因为它只针对单个实体触发。为每个实体更新调用20个更新前的订阅者似乎没有得到很好的优化？

Answer 1

EntityListener仅附加到一个实体，而EventSubscriber 为所有实体调用方法。

您无法将EntityListeners与EventListeners / EventSubscribers进行比较。

Different from Implementing Event Listeners an Entity Listener is invoked just to the specified entity.

实体监听器：An entity listener is a lifecycle listener class used for an entity.

偶数听众：They sit at a level above the entities and allow you to implement re-usable behaviors across different entity classes.

引用@stof关于事件监听器和事件订阅者之间的差异：

订阅者的主要优势（以及Symfony切换的原因）   对于他们来说，2.1）是它保持对事件的了解   而不是在服务定义中，使其更容易重用   其他环境中的监听器（例如，Silex，这就是原因   Symfony代码已更改。）

另一方面，通过服务定义注册监听器   为捆绑的DI设置提供了更大的灵活性（允许添加   有条件地基于配置的标签）

Symfony / Doctrine EventSubscriber vs EntityListener

1 个答案: