Vous n'allez pas trouver ici une bonne réponse, claire et déterministe. Dans l'ensemble, vous devez répartir les événements dans votre module là où vous et vos utilisateurs en avez besoin - si vous ne pouvez penser à aucun endroit où ils pourraient être nécessaires, vous n'avez pas besoin de les répartir. Magento lui-même émet tellement d'événements à tellement d'endroits différents (pré / post-dispatch du contrôleur, toute opération crud, etc.) que votre module enverra déjà un certain nombre d'événements utiles sans que vous ne fassiez rien.
Étant donné que cela n'est pas satisfaisant, vous souhaitez que votre module distribue un événement lorsqu'il y a une action que votre module entreprend et que vos utilisateurs pourraient vouloir ajouter, supprimer des éléments, modifier ou entreprendre une action distincte indépendante de l'action d'origine. Par exemple - Magento a un visitor_initévénement qui ne fait pas partie de sa suite standard d'événements générés automatiquement. Cet événement permet aux programmeurs de modifier l'objet visiteur avant que Magento n'enregistre les données. Ceux - ci était aucune façon les développeurs de modules originaux déterministe saventc'est là qu'un événement devait être ajouté - il provenait probablement de demandes de fonctionnalités et / ou d'entretiens avec les utilisateurs du système. Sachez ce que vos utilisateurs veulent, et s'il n'est pas possible / pratique de créer une interface utilisateur / interface utilisateur pour les laisser le faire via l'administrateur, ajoutez un crochet d'événement afin qu'un autre programmeur puisse le faire pour eux.
Moins sexy, l'ajout d'événements peut également être un moyen peu coûteux pour permettre aux développeurs (soit vos utilisateurs, soit même votre équipe) d'ajouter des fonctionnalités dans un morceau de code noueux que tout le monde a peur de toucher. Plop votre dispatchEventappel au milieu du code, accrochez-vous, et vous pouvez ajouter votre fonctionnalité sans perturber le code dans la portée d'origine. [Éditeur: Vous devriez également refactoriser ce code horrible à un moment donné]
En termes de performances, l'ajout d'un événement à distribuer dépend de l'endroit où vous l'ajoutez. Lorsque vous appelez un dispatchévénement, Magento doit effectuer quelques appels PHP supplémentaires, interroger la configuration pour tous les observateurs configurés, puis appeler les observateurs. Fait une fois, il s'agit d'un ajout bon marché dans le cadre d'une expédition Magento standard. Cependant, fait à plusieurs reprises (par exemple, avant chaque rendu de bloc), cela peut s'additionner. Il n'y a pas de bonne règle empirique ici - comme toujours, la bonne réponse est le profil.
Enfin, avec Magento 2 w / r / t, il est encore trop tôt pour le dire. Tout ce qui précède s'applique toujours - cependant le système de plug-in ajoute quelques rides. Les plugins sont, d'un point de vue, un moyen de créer un comportement de type événement pour tout appel de méthode publique dans Magento. En théorie, si vous concevez correctement vos classes, vous ne devriez jamais avoir besoin d'un événement. Cependant, dans la pratique, déposer un événement dans un peu de code de méthode protégé ou privé sera une solution tentante pour les développeurs de Magento lorsque l'alternative est un long processus de refactoring. De plus, la création d'un événement spécifiquement nommé peut souvent créer une expérience plus conviviale pour les développeurs utilisant votre module.
J'espère que cela pourra aider!