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