Тут ви не збираєтесь знайти хорошої, чіткої, детермінованої відповіді. За великим рахунком, ви повинні відправляти події у своєму модулі там, де вам та вашим користувачам потрібні - якщо ви не можете придумати де-небудь, де вони можуть знадобитися, вам не потрібно їх відправляти. Сам Magento випускає стільки подій у стільки різних місць (диспетчер перед / після відправлення контролера, будь-яка груба операція тощо), що ваш модуль вже відправить ряд корисних подій, не роблячи нічого.
Оскільки це незадовільно, ви хочете, щоб ваш модуль відправляв подію, коли відбувається якась дія, яку ваш модуль здійснює, щоб ваші користувачі могли захотіти додавати елементи, видаляти елементи, змінювати або робити окрему дію незалежно від оригінальної дії. Наприклад, у Magento є visitor_initподія, яка не є частиною його стандартного набору автоматично створених подій. Ця подія дозволяє програмістам змінювати об'єкт відвідувача перед тим, як Magento реєструє дані. Це не дозволило розробникам оригінальних модулів детерміновано знатисаме тут потрібно було додати подію - вона, ймовірно, виходила із запитів на функції та / або інтерв'ю з користувачами системи. Знайте, чого хочуть ваші користувачі, і якщо це неможливо / практично створити UI / UX, щоб дозволити це робити через адміністратора, додайте гачок події, щоб інший програміст міг це зробити за них.
Менш сексуально, додавання подій також може бути дешевим способом дозволити розробникам (або вашим користувачам, або навіть вашій команді) додати деяку функціональність у загальний біт коду, до якого всі бояться торкнутися. Перекладіть свій dispatchEventдзвінок посередині коду, підключіть його, і ви можете додати свою функціональність, не порушуючи код у вихідній області застосування. [Редактор: Також вам слід змінити цей жахливий код в якийсь момент]
Ефективність роботи, додавання події для відправки буде залежати від місця її додавання. Під час виклику dispatchподії Magento потрібно здійснити кілька додаткових дзвінків PHP, запитувати конфігурацію для будь-яких налаштованих спостерігачів, а потім викликати спостерігачів. Зроблено один раз, це дешеве доповнення в обсязі стандартної Magento відправки. Однак, що робиться неодноразово (скажімо, перед кожним візуалізацією блоку), це може скластися. Тут немає хорошого правила - як завжди правильна відповідь - профіль.
Нарешті, з / п / т Magento 2, говорити ще рано. Все вищезазначене все ще діє - проте система плагінів додає кілька зморшок. Плагіни - це, з однієї точки зору, спосіб створити подію на зразок поведінки для будь-якого публічного виклику методу в Magento. Теоретично, якщо ви правильно проектуєте свої класи, вам ніколи не потрібна подія. Однак на практиці перенесення події в трохи захищений або приватний код методу буде спокусливим рішенням для розробників Magento, коли альтернативою є тривалий процес рефакторингу. Крім того, створення спеціально названої події часто може створити зручніший досвід для розробників за допомогою вашого модуля.
Сподіваюся, що це допомагає!