Donc, Magento propose 2 façons de déclarer un observateur. Singleton et Model (nouvelle instance) en spécifiant la <type>balise dans Magento 1.x et l' sharedattribut dans Magento 2.
Magento 1 façon de le faire.
<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>
Version Magento 2:
<event name="event_name">
<observer name="unique_observer_name" instance="Class\Name\Here" method="methodNameHere" shared="true|false" />
</event>
Ainsi, dans le cas de Magento 1, si la <type>balise est un modèle ou un objet, la classe sera instanciée avec Mage::getModel(). Si c'est singletonou il manque, il est instancié en utilisant Mage::getSingleton().
Dans le cas de Magento 2, si sharedest falsealors la classe est instanciée en utilisant $this->_observerFactory->create() (nouvelle instance).
si sharedest vrai, il est instancié en utilisant $this->_observerFactory->get()(singleton).
L'idée d'observateur d'événement est très similaire entre les deux versions, mais la plupart des observateurs de Magento 1 sont utilisés en tant que singletons, car la typebalise est manquante et dans Magento 2, la plupart des observateurs (je pense tous) l'ont fait shared="false".
Je suis perplexe. Quand devrais-je utiliser des singletons et quand devrais-je utiliser de nouvelles instances pour les observateurs?
La version Magento (1 ou 2) n’est pas importante ici.
Un cas d'utilisation simple ferait pour chaque approche (nouvelle instance ou singleton)
typeattribut du tout, je le passe généralement maintenant.typebalise n'est la même chose que<type>singleton</type>. Alors, quelle est la raison pour laquelle nous faisons les observateurs singletons?Réponses:
Il n'y a qu'un seul cas d'utilisation, où un singleton pour les observateurs aurait un sens. C’est lorsque vous observez deux événements qui dépendent l’un de l’autre et que vous souhaitez obtenir quelque chose lors du premier événement, mais que vous le traitez lors du deuxième événement. Vous pouvez également utiliser le registre ici, mais ce serait quelque chose d'encore plus global, donc un singleton et une variable de classe protégée sont une bonne solution.
En réalité, cela ne se produit presque jamais, mais magento 1 et 2 utilisent par défaut shared = true
La raison probable pour laquelle singleton est par défaut dans magento: la micro-optimisation! Quelqu'un a pensé que cela économiserait beaucoup de temps sans avoir à créer les objets encore et encore. Cela peut être vrai pour certains événements appelés plusieurs centaines de fois au cours d’une demande, mais il est même raisonnable de le faire par défaut pour les cas de mauvaise utilisation des événements.
la source
_save_beforeet_save_afterque les actions sur save after dépendent de quelque chose_save_before. Duh! comment aurais-je pu le manquer?shared=truepar défaut .Par défaut, Magento utilise le singleton pour enregistrer les ressources à l'intérieur de la boîte. modèle des besoins d’exploitation de processus simultanés car ils ont besoin de stocker et de conserver des données individuellement. en singleton, l'objet devient volatil dès que de nouvelles données ont été chargées.
Magento 2.0 utilise jusqu'à présent des objets partagés. Magento 2.0 possède des destructeurs très bien écrits qui gardent la mémoire nettoyée dès que le travail est fait!
la source