Observadores de eventos de Magento: Singleton versus modelo

45

Entonces Magento ofrece 2 formas de declarar un observador. Singleton y Model (nueva instancia) especificando la <type>etiqueta en Magento 1.xy especificando el sharedatributo en Magento 2.

Magento 1 forma de hacerlo.

<events>
    <event_name>
        <observers>
            <unique_observer_name>
                <type>model|object|singleton|null</type>
                <class>class/alias_here</class>
                <method>methdNameHere</method>
            </unique_observer_name>
        </observers>
    </event_name>
</events>

Versión de Magento 2:

<event name="event_name">
    <observer name="unique_observer_name" instance="Class\Name\Here" method="methodNameHere" shared="true|false" />
</event>

Entonces, en el caso de Magento 1, si la <type>etiqueta es modelo u objeto, se instanciará la clase con Mage::getModel(). Si está singletono falta, se instancia usando Mage::getSingleton().

En el caso de Magento 2, si sharedes falseasí, la clase se instancia usando $this->_observerFactory->create() (nueva instancia).
si sharedes verdadero, se instancia usando $this->_observerFactory->get()(singleton).

Entre las dos versiones, la idea del observador de eventos es muy similar, pero la mayoría de los observadores en Magento 1 se usan como singletons, porque typefalta la etiqueta y en Magento 2 la mayoría (creo que todos) tienen los observadores shared="false".

Estoy confundido. ¿Cuándo debo usar singletons y cuándo debo usar nuevas instancias para observadores?
La versión de Magento (1 o 2) no es importante aquí.
Un caso de uso simple sería adecuado para cada enfoque (nueva instancia o singleton)

Marius
fuente
También luchando con eso. Aunque no es necesario usar el typeatributo en absoluto, por lo que generalmente lo omito ahora.
Simon
@ Simon, generalmente me lo salteo. Ninguna typeetiqueta es lo mismo que <type>singleton</type>. Entonces, ¿cuál es la razón por la que estamos haciendo observadores singletons?
Marius
Esa es de hecho una buena pregunta. Es por eso que lo voté. Solo quería señalar que también puede omitirlo por completo.
Simon

Respuestas:

36

Solo hay un caso de uso, donde el sentido único para los observadores tendría sentido. Eso es cuando observa dos eventos que dependen el uno del otro y desea obtener algo durante el primero, pero procesarlo durante el segundo evento. También podría usar el registro aquí, pero eso sería algo aún más global, por lo que Singleton y una variable de clase protegida es una buena solución.

En realidad, esto casi nunca sucede, pero el uso de magento 1 y 2 por defecto es shared = true

Probablemente la razón por la que singleton es predeterminado en magento: ¡microoptimización! Alguien pensó que ahorraría mucho tiempo no tener que crear los objetos una y otra vez. Puede ser cierto para algunos eventos que se llaman unos cientos de veces durante una solicitud, incluso puede ser razonable hacerlo de manera predeterminada para los casos de mal uso de los eventos.

Flyingmana
fuente
55
A las costuras les gusta una buena explicación. . Y ahora que lo mencionas, me golpeó en la cabeza ... un caso de uso real para los hijos únicos: cuando se quiere observar _save_beforey _save_aftery las acciones en Guardar después de depender de algo de _save_before. Duh! ¿Cómo podría haberlo perdido?
Marius
"que es, por qué magento2 usa por defecto shared = false" Esto está mal. Magento 2 utiliza shared=truepor defecto .
Mage2.PRO
gracias, actualicé la respuesta
Flyingmana
1

Magento por defecto usa el singleton para que ahorre recursos dentro de la caja. el modelo de dos necesidades operativas de proceso concurrente ya que necesitan almacenar y retener datos individualmente. en singleton, el objeto se vuelve volátil en cuanto se cargan nuevos datos.

¡Por adelantado, magento 2.0 utiliza objetos compartidos para utilizar ... magento 2.0 tiene destructores muy bien escritos que mantienen limpia la memoria tan pronto como se hace el trabajo!

Vipul Dadhich -TyLabs
fuente