Является ли регистрация bean-компонентов в контексте Spring антипарадигмой?

Question

Предположим, что у нас есть файл конфигурации в качестве ресурса нашего приложения.Этот файл ресурсов содержит ключ, который включает в себя массив объектов, каждый из которых объявляет конфигурацию для создания экземпляров Foo объектов.

Обычно мы можем аннотировать наши типы с помощью @Component|Service|Configuration|..., следовательно, он будет доступен в контексте приложения Spring, или мы могли бы просто объявить фабрики бинов, чтобы показать, как объект должен быть создан в контейнере приложения.

На этот раз я хотел бы создать несколько объектов одного типа, например Foo, но с другой конфигурацией.Каждый из них будет иметь уникальное имя bean-компонента, поэтому я мог бы @Autowired всех этих bean-компонентов просто объявить поле Map<String, Foo>, где оно вставляется Spring Framework как список пар ключ-значение, содержащий bean-компоненты, связанные с их именами.

Вопрос более философский.Spring Framework использует принципы инверсии управления с использованием внедрения зависимостей , поэтому мы разгрузим управление жизненным циклом объектов, от которых зависят наши классы.

IsЭто анти-парадигма, чтобы регистрировать эти компоненты программно, так как Spring не заботится о том, что я сделал в файле конфигурации?

Answer 1

Используя BeanDefinitionRegistryPostProcessor, вы можете программно определить конфигурацию для компонента.Это просто конфигурация компонента, но не экземпляр компонента.Spring создаст экземпляр компонента и будет управлять его жизненным циклом на основе конфигурации компонента.

Таким образом, в конце компонент все еще создается и управляется бином, который не нарушает философию IoC, которая продвигает контейнер для создания бина, а не самого разработчика.

Answer 2

Регистрация компонентов Spring и Spring, управляющих жизненным циклом этих компонентов, являются отдельными операциями.Нужно сделать все бины доступными для Spring, чтобы Spring мог управлять их жизненным циклом.

Существует несколько способов регистрации бинов (не исчерпывающий список).

• XMLфайлы

• Java-аннотации - @ComponentScan / @Configuration / @Component - некоторые примеры такой регистрации.

• PostProcessors - это еще один способ сделать то же самое.

• spring.factories - Вы можете даже добавить все свои бины в META-INF/spring.factories подспециальное свойство и сделайте все компоненты доступными для вашего загрузочного приложения Spring.

• Индекс компонента-кандидата
• Функциональный стиль регистрации с поставщиками, который ленив и без отражениярасходы.См. [1]

Вы можете даже смешивать и сочетать один или несколько из вышеперечисленных механизмов, и Spring выполнит их все.

Чтобы ответить на ваш конкретный вопрос, указанный выше:

> Is it an anti-paradigm to register that beans programmatically, since Spring does not take care of what I did in the configuration file?

Определенно нет.Вы можете зарегистрировать бины одним или несколькими способами, но это не меняет того, как Spring будет относиться к ним, когда дело доходит до связывания зависимостей.

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

Когда вы запрашиваете все bean-компоненты определенного типа в Map<String, Foo>, Spring предоставит вам всезависимости независимо от того, как они были зарегистрированы.

Придерживайтесь нескольких механизмов регистрации (как можно меньше), которые работают для вас, чтобы ваши товарищи по команде могли понять и поддерживать, как бины подключаются,

[1] - Что нового в Spring 5.x

Answer 3

Как вы указали, IoC / DI полностью делегирует ответственность за построение объектов и управление ими фреймворку.

Сказав это, если вы расширяете фреймворк, т. Е. Внедряете BeanDefinitionRegistryPostProcessor - Spring по-прежнему будет управлять компонентами и следующими инъекциями.Это не идет вразрез с определением IoC.

Теперь, вдаваясь в дальнейшие подробности, если вы программно получаете доступ к контексту во время выполнения из разных классов для получения bean-компонентов, вы нарушите шаблон IoC.Делая это, вы вернете классам ответственность за знание того, как построить себя.

Мое правило: чем меньше мои классы знают о деталях реализации Spring (слабая связь), тем лучше. Кроме того, если вы регистрируете bean-компоненты после жизненного цикла Spring (не создавая bean-компоненты после BeanFactoryPostProcessor выполняется), вы просто будете следовать естественному пути фреймворка.