[Doctrine Events] "drawbacks and advantages" of different listeners

[lyrixx]

In the doc we say:

There are different ways to listen to these Doctrine events:

• Lifecycle callbacks, they are defined as public methods on the entity classes and
  they are called when the events are triggered;
• Lifecycle listeners and subscribers, they are classes with callback
  methods for one or more events and they are called for all entities;
• Entity listeners, they are similar to lifecycle listeners, but they are
  called only for the entities of a certain class.

These are the drawbacks and advantages of each one:

• Callbacks have better performance because they only apply to a single entity
  class, but you can't reuse the logic for different entities and they don't
  have access to :doc:Symfony services </service_container>;
• Lifecycle listeners and subscribers can reuse logic among different entities
  and can access Symfony services but their performance is worse because they
  are called for all entities;
• Entity listeners have the same advantages of lifecycle listeners and they have
  better performance because they only apply to a single entity class.

I want to focus on the very last point:

Entity listeners have the same advantages of lifecycle listeners and they have
better performance because they only apply to a single entity class.

So it means this one doesn't have any drawback, doesn't ?

So to me, I would use the following pattern

• Very simple code for one entity, without extra dependencies => Lifecycle callbacks
• More complexe code for one entity, with dependencies => Entity listeners
• Shared code between different kind of entities => Lifecycle listeners

And I would not talk about Lifecycle subscriber at all, since it's deprecated

[stof]

The drawback of the lifecycle callbacks is that they are bloating the entity class itself instead of allowing to separate the logic (especially if your entity class is not knowing much about the ORM itself except for mapping attributes to make it reusable). that would be another case where entity listeners might be used.

Other than that, the suggested pattern looks good.

Note that not all ORM listeners are lifecycle listeners (listeners are not really about lifecycle anyway. It is events that can be lifecycle events). So another case where you will need to use full-powered listeners is when you need to deal with other events than lifecycle events (onFlush for instance is not a lifecycle event as it relates to the whole unit of work, not to the lifecycle of a single entity). Here, lifecycle listeners is a shortcut for listeners subscribed to lifecycle events)