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)
typeatributo en absoluto, por lo que generalmente lo omito ahora.typeetiqueta es lo mismo que<type>singleton</type>. Entonces, ¿cuál es la razón por la que estamos haciendo observadores singletons?Respuestas:
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.
fuente
_save_beforey_save_aftery las acciones en Guardar después de depender de algo de_save_before. Duh! ¿Cómo podría haberlo perdido?shared=truepor defecto .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!
fuente