Observateurs d'événements Magento: Singleton versus Model


45

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)


Lutte également avec elle. Bien qu'il ne soit pas nécessaire d'utiliser l' typeattribut du tout, je le passe généralement maintenant.
Simon le

@ Simon je le passe habituellement. Aucune typebalise n'est la même chose que <type>singleton</type>. Alors, quelle est la raison pour laquelle nous faisons les observateurs singletons?
Marius

C'est effectivement une bonne question. C'est pourquoi je l'ai voté. Je voulais juste souligner que vous pouvez également le sauter complètement.
Simon le

Réponses:


36

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.


5
Les coutures sont une bonne explication. . Et maintenant que vous en avez parlé, cela m’a frappé à la tête ... un cas d’utilisation concret pour les singletons: quand vous voulez observer _save_beforeet _save_afterque les actions sur save after dépendent de quelque chose _save_before. Duh! comment aurais-je pu le manquer?
Marius

"c’est-à-dire pourquoi magento2 utilise par défaut shared = false" Ceci est faux. Magento 2 utilise shared=truepar défaut .
Mage2.PRO


thx, mis à jour la réponse
Flyingmana

1

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!

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.