Когда отправлять события в пользовательский модуль?

Это вопрос как к Magento 1, так и к Magento 2.

Я понимаю, что в качестве хорошей практики сторонним разработчикам модулей рекомендуется отправлять события в свои пользовательские модули, чтобы упростить работу с другими модулями.

Я бы хотел знать:

• где разработчик должен отправлять события в пользовательский модуль?
• есть ли рекомендуемое место для отправки событий? Например, контроллеры, модели, блоки, помощники, наблюдатели?
• Как диспетчеризация событий влияет на производительность?

Вы не найдете здесь хорошего, ясного, детерминированного ответа. В общем, вы должны отправлять события в своем модуле туда, где они нужны вам и вашим пользователям - если вы не можете думать о том, где они могут понадобиться, вам не нужно отправлять их. Magento сам генерирует так много событий в столь разных местах (диспетчерская / пост-диспетчеризация, любая грубая операция и т. Д.), Что ваш модуль уже отправит ряд полезных событий без каких-либо действий.

Так как это неудовлетворительно, вы бы хотели, чтобы ваш модуль отправлял событие, когда есть какое-то действие, которое ваш модуль предпринимает, чтобы ваши пользователи могли захотеть добавлять элементы, удалять элементы, изменять или предпринимать отдельное действие независимо от исходного действия. Например, в Magento есть visitor_initсобытие, которое не входит в его стандартный набор автоматически генерируемых событий. Это событие позволяет программистам изменять объект посетителя до того, как Magento регистрирует данные. Это не был способ, которым разработчики оригинального модуля могли детерминистически знатьэто было то место, где нужно было добавить событие - скорее всего, оно было вызвано запросами на функции и / или интервьюами с пользователями системы. Знайте, чего хотят ваши пользователи, и если невозможно / практически невозможно создать пользовательский интерфейс / UX, чтобы позволить им делать это через администратора, добавьте ловушку событий, чтобы другой программист мог сделать это для них.

Менее сексуально, добавление событий также может быть дешевым способом, позволяющим разработчикам (или вашим пользователям, или даже вашей команде) добавлять некоторые функциональные возможности в грубый кусочек кода, который все боятся трогать. Поместите ваш dispatchEventвызов в середину кода, подключитесь к нему, и вы сможете добавить свою функциональность, не нарушая код в исходной области видимости. [Редактор: В какой-то момент вам также следует изменить этот ужасный код]

С точки зрения производительности добавление события в диспетчер будет зависеть от того, где вы его добавили. Когда вы вызываете dispatchсобытие, Magento необходимо сделать несколько дополнительных вызовов PHP, запросить конфигурацию для любых настроенных наблюдателей, а затем вызвать наблюдателей. Сделано один раз, это дешевое дополнение в рамках стандартной отправки Magento. Однако, если сделать это несколько раз (скажем, перед каждым блоком рендеринга), это может сложиться. Здесь нет хорошего эмпирического правила - как всегда правильный ответ - профиль.

Наконец, с Magento 2, пока рано говорить. Все вышеперечисленное все еще применимо - однако система плагинов добавляет несколько морщин. Плагины - это, с одной стороны, способ создания поведения, похожего на событие, для любого открытого вызова метода в Magento. Теоретически, если вы разрабатываете свои классы правильно, вам никогда не понадобится событие. Однако на практике добавление события в часть кода защищенного или частного метода будет заманчивым решением для разработчиков Magento, когда альтернативой является длительный процесс рефакторинга. Кроме того, создание события с определенным именем может часто создавать дружественный опыт для разработчиков, использующих ваш модуль.

Надеюсь, это поможет!

Для Magento 1 хорошее время для бросания событий - до и после всех операций CRUD, а также до и после рендеринга. Многие из них уже представлены абстрактными классами в ядре, поэтому на практике не так много сторонних событий.

С Magento 2 ситуация иная. Поскольку публичные вызовы методов могут быть перехвачены с помощью плагинов, пользовательские события больше не нужны.
При разработке классов вместо простого обнародования каждого метода, чтобы его можно было перехватить, лучше разбить большой класс на несколько меньших классов.
Каждый из меньших классов может иметь один или два хорошо названных и приемлемых открытых метода.

Как сказал Винай, до / после операции CRUD. Другое важное место для отправки событий - это блоки формы adminhtml (если применимо). Таким образом, вы можете добавлять новые поля ввода, если вы добавили пользовательские атрибуты / поля без необходимости перезаписывать блоки формы администратора. (Это для Magento 1). См пример

Внутри Magento 1 вы можете использовать события через автоматически запускаемые события. Все, что вам нужно сделать, это установить $_eventPrefixи $_eventObjectсвойства на ваших моделях. Кроме того , вы пользовательских выстрелили контроллер события через 'controller_action_predispatch_ ' . $this->getFullActionName()и 'controller_action_postdispatch_' . $this->getFullActionName()событие на контроллере автоматически. Те могут получить вас большую часть пути туда.

Для Magento 2, держите ваши методы публичными внутри ваших классов. Это позволяет плагинам перехватывать ваши методы. Если вы выполните это, вам не придется создавать какие-либо пользовательские события.

Надеюсь, это поможет!