Причина, по которой все здесь говорят, что это неправильное использование Событий и Слушателей, заключается в том, что вся их цель - запускать асинхронно.Когда вы запускаете слушателя, содержимое этого слушателя не может быть гарантированно завершено до того, как вещь, которая его сработала, движется дальше.По этой причине они не настроены предлагать возврат.
Некоторые дополнительные сведения о том, почему вы чувствуете, что желаемая логика должна быть от слушателя, были бы полезны, возможно, мы сможем помочь вам лучшешаблон.Хотя сейчас я бы сказал, что у вас есть несколько вариантов.В порядке предпочтения:
- Абстрагируйте содержимое метода
handle()
вашего слушателя в новый класс обслуживания.Класс, который, по вашему мнению, должен получить доступ к этому Слушателю, и сам Слушатель могут ссылаться на этот класс Службы независимо друг от друга. - Не запускайте ваш класс Слушателя из События.Вместо этого создайте его экземпляр как обычный класс, а затем вызовите его метод
handle()
напрямую, чтобы получить желаемый ответ. - Установите
config(['app.queue_driver' => 'sync'])
, чтобы обеспечить синхронное срабатывание слушателей.(Обязательно верните его в следующей строке после запуска прослушивателя, который должен быть синхронным, иначе это может привести к непредвиденным последствиям для остальной части вашего приложения.) Затем измените прослушиватель так, чтобы все, что handle()
сохранялосьв свойстве, доступном новым методом Getter.Этот вариант не рекомендуется, хотя.Это можно сделать, но это так неряшливо, что я не решаюсь даже предложить это.Но я не новичок в том, что мой код делает странные вещи ради юнит-тестов, поэтому я не собираюсь предполагать, что вам известны ваши обстоятельства.