Spring IoC контейнер: Java конфигурация, @Bean и @Configuration
Центральными артефактами поддержки Java-конфигурации Spring с использованием new являются @Configuration-аннотированные классы и @Bean-аннотированные методы.
Аннотация @Bean используется для указания того, что метод создает, настраивает и инициализирует новый объект, который будет управляться контейнером Spring IoC. Для сравнения с XML-конфигурацией Spring <beans/>, аннотация @Bean играет ту же роль, что и элемент <bean/>. Вы можете использовать аннотированные @Bean методы с любым Spring @Component. Однако они чаще всего используются с bean-компонентами @Configuration.
Аннотирование класса с помощью @Configuration указывает на то, что его основное назначение - источник определений бина. Кроме того, классы @Configuration позволяют определять зависимости между компонентами, вызывая другие методы @Bean в том же классе. Простейший из возможных классов @Configuration выглядит следующим образом:
Java
@Configuration
public class AppConfig {
@Bean
public MyService myService() {
return new MyServiceImpl();
}
}
Kotlin
@Configuration
class AppConfig {
@Bean
fun myService(): MyService {
return MyServiceImpl()
}
}
Предыдущий класс AppConfig эквивалентен следующему Spring <beans/> XML:
<beans>
<bean id="myService" class="com.acme.services.MyServiceImpl"/>
</beans>
Полная @Configuration против "облегченного" режима @Bean?
Когда методы @Bean объявляются в классах, которые не аннотируются @Configuration, они называются обработанными в "облегченном" режиме. Методы bean-компонентов, объявленные в @Component или даже в простом классе с другой основной целью содержащего класса, считаются "облегченными", а метод @Bean является своего рода бонусом. Например, сервисные компоненты могут предоставлять представление управления контейнеру с помощью дополнительного метода @Bean для каждого применимого класса компонентов. В таких сценариях методы @Bean являются механизмом фабричного метода общего назначения.
В отличие от полной @Configuration, облегченные @Bean методы не могут объявлять межбиновые зависимости. Вместо этого они оперируют внутренним состоянием содержащего их компонента и, необязательно, аргументами, которые они могут объявлять. Поэтому такой метод @Bean не должен вызывать другие методы @Bean. Каждый такой метод является буквально только фабричным методом для конкретной ссылки на компонент, без какой-либо специальной семантики времени выполнения. Положительным побочным эффектом здесь является то, что подклассы CGLIB не должны применяться во время выполнения, поэтому нет никаких ограничений с точки зрения разработки класса (то есть, содержащий класс может быть final и т. д.).
В обычных сценариях методы @Bean должны объявляться в классах @Configuration, гарантируя, что всегда используется "полный" режим и поэтому ссылки на перекрестные методы перенаправляются в управление жизненным циклом контейнера. Это предотвращает случайный вызов одного и того же метода @Bean посредством обычного вызова Java, что помогает уменьшить тонкие ошибки, которые трудно обнаружить при работе в "облегченном" режиме.
Читайте также:
- Spring IoC контейнер: использование стандартных аннотаций JSR 330, внедрение зависимостей с @Inject и @Named
- Spring IoC контейнер: аннотации JSR 330, @Named и @ManagedBean - стандартные эквиваленты аннотации @Component
- Spring IoC контейнер: ограничения стандартных аннотаций JSR 330
Комментарии
Отправить комментарий