Laravel Broadcasting: уведомление и событие

Ответ 1

Много подумав, я узнал, что они сделаны для разных вещей, вот что я понял:

Уведомления:

Рассмотрите facebook, каждый раз, когда вы входите в систему, вы видите кучу уведомлений о вещах, которые произошли во время вашего отсутствия, а также если вы присутствуете, вы видите живые уведомления.

между тем вы получаете сообщения об уведомлениях, которые вы хотите... это именно то, что делает Laravel Notifications. вы можете использовать метод notify в своих красноречивых моделях, таких как App\User о чем-то вроде OrderApproved который будет делать все, что вы планировали сделать для вас, как отправка sms этому пользователю. а также вы можете сохранить одно мгновение этого уведомления в базе данных, поэтому, когда пользователь возвращается, он или она может видеть, что вы одобрили их заказ.

Мероприятия:

это когда что-то происходит, например, когда создается новый пользователь, и вы хотите делать разные вещи, такие как отправка проверки электронной почты, отправка контрольных смс и т.д. Именно поэтому вы создаете событие, чтобы вы могли обрабатывать разные логики этого события с помощью прослушивателей. когда дело доходит до трансляции, вы можете использовать интерфейс ShouldBroadcast на своем мероприятии, и оттуда вы можете синхронизировать данные с вашей административной панелью, чтобы зарегистрировать нового пользователя. это будет полезно, когда администратор просмотрит список пользователей и не перезагрузит страницу, которую вы можете использовать Laravel Echo для получения этого события на панели администратора и добавления нового зарегистрированного пользователя в список.

Вывод:

это действительно зависит от того, что вам нужно, если вы просто хотите что-то обновить в своем интерфейсе, возможно, события - это то, что вам нужно. но если вам нужно сделать больше, вы можете использовать оповещения.

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

надеюсь, что это поможет другим.

Ответ 2

В представленном ответе отсутствует imo, так это то, что в большинстве случаев они используются как вместо 1, так и для другого, что, по-видимому, является тон предоставленного ответа/вопроса.

Событие является чем-то значительным в вашем приложении. Предположим, что ваше приложение является веб-магазином.

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

Поэтому хорошим подходом было бы использование Event под названием ProductPurchased. Это событие может иметь Listeners, эти слушатели в этом случае должны выполнить все шаги, которые необходимо выполнить, когда пользователь покупает продукт.

например: ProductPurchased (event)

• BillClient (eventlistener)
• GenerateInvoice (eventlistener)
• notifyClient (eventlistener)
• ...

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

Таким образом, в event-listenener notifyClient мы можем создать уведомление. Это уведомление несет ответственность за отправку сообщения клиенту. Это может быть сообщение SMS/Slack-message/Email/...

И, как вы упомянули, оба события и уведомления могут быть помещены в очередь или могут транслироваться.