Блог

Сначала я опишу контекст.
У меня много уведомлений, которые ссылаются на изменения в Offer , for example: offerEditedBySeller, offerEditedByAdmin, offerTurnOff, etc . Они запускаются во многих местах в контроллерах.
Теперь я внедряю расширенный кеш и хочу создать событие OfferChange , в котором кеш для конкретного предложения будет перезагружен. Сначала я хотел запускать эти уведомления в событиях, но понял, что для того, чтобы это работало, мне придется дублировать каждое уведомление.
Например, давайте предположим, что у меня есть событие( new OfferEdited() ) . Его слушателями будут RefreshCacheForOffer, SendNotificationsAboutOfferEdit и т. Д. Для каждого подобного уведомления offerEdited мне нужно создать прослушиватель SendNotificationsAboutOfferEdit , который просто запускает определенное уведомление. Я думаю, что это не то, чего я хочу достичь.

Есть ли способ привязать события / прослушиватели к уведомлению? Неважно, будет ли это offerEdited , offerApproved или offerDisapproved это будет привязка к событию OfferChange , что приведет к запуску слушателя RefreshCacheForOffer и следующему конкретному заданию. Таким образом, мне не пришлось бы изменять код в каждом действии контроллера и создавать множество ненужных событий и прослушивателей. Возможно ли это?

Редактировать:
Я знаю, что могу просто сделать:

 $user->notify(new offerEdited($offer));
event( new OfferChange($offer) );
  

Но я надеюсь, что есть способ лучше организовать его.

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

 class Offer extends Model
{

    protected static function booted()
    {
        static::updated(function ($user) {
            // check for condition and trigger event such as OfferEditedBySeller
        });
    }
}
  

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

В качестве альтернативы, не беспокойтесь о событиях / прослушивателях — просто отправляйте свои уведомления с контроллера или из «созданных» или «обновленных» событий модели. Вырежьте посредника (события / прослушиватели), и у вас будет более четкий код, которому легче следовать.

События / прослушиватели хороши, когда вам нужно отделить и абстрагироваться, но если вы делаете явные вещи, то вам может быть проще их не использовать.