Spring Framework. Event Listener
ฝัง
- เผยแพร่เมื่อ 7 ก.พ. 2025
- 🌱 Обработка событий приложения в Spring Framework 🌱
В этом видео вы узнаете, как использовать инструменты Spring Framework для обработки событий, а также создадите свои события и обработаете их. Познакомитесь с интерфейсом ApplicationListener, а также аннотацией EventListener для обработки событий! 🚀✨
#java #programming #spring #springframework #обучение #javatutorial #eventlistener
Курс по Spring Framework и Spring Boot в одном видео: th-cam.com/video/vB9BVTz5xrI/w-d-xo.html
Подписывайтесь на телеграм-канал: t.me/software_noise
Супер круто, с первого раза тяжело понять, но ничего, будем разбиратся
Последняя часть с асинхронным обработчиком уж больно резво прошла :) Не стесняйтесь чуть притормаживать и делать разъяснения 🙏
Что было непонятно? Могу попытаться ответить в комментариях=)
отлично рассказал
крутое видео, практика очень интересная, много узнал.
интересно как выузнали про ApplicationEventMulticaster?
Спасибо!
Довольно часто при обработке событий хочется чтобы они обрабатывались асинхронно, поэтому я использую ApplicationEventMulticaster довольно давно и не припомню как я про него узнал, но скорее всего это была дока или какая-то статья=)
Спасибо за Event Listener, как раз ждал, за примеры, особенно за асинхронную обработку. Ну как-то все так быстро )) С асинхронной обработкой как-то пока тяжело усвоилось.
Получается как только мы внедрил бин ApplicationEventMulticaster, то обработка собитий происходит асинхронно?
Я решил не удлинять видео, но, действительно, есть пара слов, которые стоило бы добавить.
1) На самом деле, с помощью EventListener Spring просто реализует паттерн Observer. Вот, я написал реализацию на чистой Java, без использования Spring - gist.github.com/PavelVil/560c1b9813c1bceee3b374b2e1c39035.
2) Да, если мы добавляем ApplicationEventMulticaster и выставляем ему асинхронный экзекьютор, то все наши события выполняются асинхронно. Если не выставить асинхронный экзекьютор, то будет использоваться org.springframework.core.task.SyncTaskExecutor, который выполняет все события синхронно.
3) Также у org.springframework.context.ApplicationListener, помимо метода onEvent, есть метод boolean supportsAsyncExecution(). По умолчанию он возвращает true. Если изменить на false, то обработка всегда выполняется внутри исходного потока, опубликовавшего событие.
@@PavelVil Спасибо за развернутый ответ
скажите в чем основная фишка использования EventListener? Выглядит так что некоторые фишки я могу решить просто заинжектив бин в класс, а другие решаться с помощью кафки.
EventListener работает в рамках одного приложения, в то время как Kafka предназначен для стриминга событий и обмена данными между различными приложениями.
Да, использование EventListener можно заменить обычным внедрением зависимостей. Однако с помощью EventListener можно отделить логику обработки некоего события от основной бизнес-логики и гибко настроить асинхронную обработку событий. Если в приложении много событий, то все их обработчики можно держать в одном пакете, разделить их там и управлять ими.
Правильно ли использовать Event listener для передачи объектов между компонентами приложения для достижения низкого coupling?
Да, использование слушателей может снизить сцепление между компонентами и в целом способствует построению более гибкой архитектуры за счет изолированности издателя и подписчика событий. Однако в такой системе все равно присутствует непрямая связь между компонентами, что может усложнить понимание того, как выполняется код.
Если стоит выбор между внедрением бина и передачей через события, лучше внедрять бин.
А если внедрять, то только через конструктор же (через поле не по фен-шую, так как сложно тестировать, через сеттер тоже иммутабельность нарушается)... 🤷
Насколько неправильно 😅 в спринг часть объектов локально создавать в методах через new?
Можно использовать внедрение как через поле, так и через сеттеры. Однако внедрение через конструктор считается наиболее предпочтительным. Фактически, выбор метода зависит от конкретной ситуации.
Создание объектов через оператор new противоречит основным концепциям Spring. Фреймворк фокусируется на управлении объектами и их зависимостями, предоставляя контейнер для управления жизненным циклом и внедрением зависимостей. Использование new фактически выходит за пределы контекста Spring.
Однако в некоторых ситуациях, например, при создании вспомогательных объектов, которые не являются бинами и не имеют зависимостей, локальное создание через new может быть приемлемым. Это может включать в себя создание простых объектов для временного использования внутри метода, которые не требуют управления контейнером.