Spring Framework. Event Listener

[@caffeinejavacode1475]

крутое видео, практика очень интересная, много узнал. интересно как выузнали про ApplicationEventMulticaster?

[@PavelVil]

Спасибо! Довольно часто при обработке событий хочется чтобы они обрабатывались асинхронно, поэтому я использую ApplicationEventMulticaster довольно давно и не припомню как я про него узнал, но скорее всего это была дока или какая-то статья=)

[@obusis]

Последняя часть с асинхронным обработчиком уж больно резво прошла :) Не стесняйтесь чуть притормаживать и делать разъяснения 🙏

[@PavelVil]

Что было непонятно? Могу попытаться ответить в комментариях=)

[@ANDREYQIWS]

Супер круто, с первого раза тяжело понять, но ничего, будем разбиратся

[@ZamalSpace]

Спасибо за Event Listener, как раз ждал, за примеры, особенно за асинхронную обработку. Ну как-то все так быстро )) С асинхронной обработкой как-то пока тяжело усвоилось. Получается как только мы внедрил бин ApplicationEventMulticaster, то обработка собитий происходит асинхронно?

[@PavelVil]

Я решил не удлинять видео, но, действительно, есть пара слов, которые стоило бы добавить. 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, то обработка всегда выполняется внутри исходного потока, опубликовавшего событие.

[@ZamalSpace]

@@PavelVil Спасибо за развернутый ответ

[@aleksandr_4638]

отлично рассказал

[@alexandr6055]

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

[@PavelVil]

EventListener работает в рамках одного приложения, в то время как Kafka предназначен для стриминга событий и обмена данными между различными приложениями. Да, использование EventListener можно заменить обычным внедрением зависимостей. Однако с помощью EventListener можно отделить логику обработки некоего события от основной бизнес-логики и гибко настроить асинхронную обработку событий. Если в приложении много событий, то все их обработчики можно держать в одном пакете, разделить их там и управлять ими.

[@obusis]

Правильно ли использовать Event listener для передачи объектов между компонентами приложения для достижения низкого coupling?

[@PavelVil]

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

[@obusis]

А если внедрять, то только через конструктор же (через поле не по фен-шую, так как сложно тестировать, через сеттер тоже иммутабельность нарушается)... 🤷

[@obusis]

Насколько неправильно 😅 в спринг часть объектов локально создавать в методах через new?

[@PavelVil]

Можно использовать внедрение как через поле, так и через сеттеры. Однако внедрение через конструктор считается наиболее предпочтительным. Фактически, выбор метода зависит от конкретной ситуации.

[@PavelVil]

Создание объектов через оператор new противоречит основным концепциям Spring. Фреймворк фокусируется на управлении объектами и их зависимостями, предоставляя контейнер для управления жизненным циклом и внедрением зависимостей. Использование new фактически выходит за пределы контекста Spring. Однако в некоторых ситуациях, например, при создании вспомогательных объектов, которые не являются бинами и не имеют зависимостей, локальное создание через new может быть приемлемым. Это может включать в себя создание простых объектов для временного использования внутри метода, которые не требуют управления контейнером.