Документация Spring для сканирования компонентов и настройки
Я искал ответ на этот вопрос, но мой поиск вуду, должно быть, не совсем точен.
На работе я заметил, что для инициализации наших Java-объектов предпочтение отдается использованию Spring Configuration и @Beans. Хотя с этим подходом проблем нет, я подумал, что переключение на @Component (с ComponentScan) может
- Немного упростить код
- Сделайте нас более понятными с хорошими практиками Spring
Но, размышляя об этом, мне трудно объяснить, почему я считаю это хорошей практикой. Насколько я понимаю, @Bean полезен для инициализации устаревшего или не-Springified кода. Это может побудить меня рассматривать @Component как хорошую практику.
Преимущество подхода @Bean в том, что он централизует инициализацию. Это немного легче понять, в отличие от @Component, который не так интуитивно понятен.
Есть ли у Spring какая-нибудь хорошая документация о плюсах и минусах каждого подхода? Или руководство по передовой практике по этой теме?
Ответы 1
Класс @Configuration с @ Bean-s внутри называется «конфигурацией на основе Java». И он более гибкий, чем «Конфигурация на основе аннотаций» (@Component).
Совершенно допустимо иметь конфигурацию Java и сканирование аннотированных компонентов в одном проекте, потому что они служат для разных целей.
@Component (@Service, @Repository и т. д.) Используются для автоматического обнаружения и автоматической настройки bean-компонентов.
Аннотация @Bean используется для явного объявления одного bean-компонента вместо того, чтобы позволить Spring делать это автоматически. Таким образом вы можете предоставить больше настроек для bean-компонента.
С @Bean вы можете делать следующее. Но это невозможно с @Component:
@Bean
public MyService myService(boolean someCondition) {
if (someCondition) {
return new MyServiceImpl1();
} else {
return new MyServiceImpl2();
}
}
Могу сказать, что обычно в проектах используются оба подхода. Это не одно против другого. Иногда вам нужно настроить bean-компоненты из сторонних библиотек, в этом случае вам нужно предоставить настроенный bean-компонент для контекста через конфигурацию на основе Java.
Кроме того, конфигурации на основе Java очень удобны в интеграционных тестах.
Это было одно из замечательных преимуществ фасоли. Но я заметил, что можно определить компонент как компонент для тестирования, и он работает.
Я говорил об интеграционных тестах с небольшим объемом. Когда вы используете аннотацию @ContextConfiguration для предоставления только bean-компонентов для тестов. Но отвечая на ваш вопрос «Есть ли причина игнорировать компонент и просто придерживаться Bean?» - нет, такой причины нет
Спасибо за понимание @Pospolita Nikita
Конфигурация на основе Java является предпочтительнее для тестирования, поскольку вы импортируете только классы конфигурации, необходимые для тестирования любого фрагмента приложения, который вы хотите. например MyDatabaseConfigurion, MyServiceConfiguration. ComponentScanning быстро становится беспорядочным, так как у вас нет центральной точки отсчета для определения bean-компонентов, и если вы хотите протестировать только часть своего приложения, вы, скорее всего, в конечном итоге загрузите больше, чем необходимо. Классы конфигурации предоставляют центральную точку доступа.
Есть ли у сообщества Spring какие-нибудь предпочтения? На самом деле с Компонентом всегда будет использоваться смешанный подход. Есть ли причина игнорировать компонент и просто придерживаться Bean?