Как настроить Spring bean с помощью Java-конфигурации?

Question

Как настроить Spring bean с помощью Java-конфигурации?

Тип вопроса: Spring Вероятность: 10% Категория: Java Разработчик

Ответ

Java-конфигурация в Spring — это типобезопасная альтернатива XML, использующая аннотации @Configuration и @Bean.

Базовый пример:

@Configuration // Указывает, что класс содержит конфигурацию бинов
public class AppConfig {

    @Bean // Результат метода регистрируется как bean в Spring Context
    public MyService myService() {
        return new MyServiceImpl();
    }

    @Bean
    public DataSource dataSource() {
        return new DriverManagerDataSource("jdbc:h2:mem:testdb", "sa", "");
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource dataSource) { // Внедрение зависимости
        return new JdbcTemplate(dataSource);
    }
}

Ключевые преимущества перед XML:

Типобезопасность и рефакторинг: Ошибки конфигурации обнаруживаются на этапе компиляции.
Гибкость: Можно использовать любую Java-логику при создании бина.
Условная конфигурация: Аннотации @Profile, @ConditionalOnProperty и другие.

Импорт конфигураций:

@Configuration
@Import({DatabaseConfig.class, SecurityConfig.class}) // Импорт других @Configuration классов
@ComponentScan("com.example.services") // Сканирование пакетов на наличие @Component
public class MainConfig {
}

Ответ 18+ 🔞

Ну слушай, вот эта ваша Java-конфигурация в Spring — это же просто праздник какой-то, ёпта! Раньше-то сидели, в этих XML-файлах ковырялись, глаза сломаешь, пока найдешь, где там запятую не там поставил. А тут — чистая джава, типобезопасность, рефакторинг. Охуенно же!

Смотри, как просто всё, блядь. Берёшь обычный класс и вешаешь на него @Configuration. Всё, приехали. Это типа кричит Спрингу: «Эй, мудила, смотри сюда, у меня тут рецепты бинов написаны!»

@Configuration // Указывает, что класс содержит конфигурацию бинов
public class AppConfig {

    @Bean // Результат метода регистрируется как bean в Spring Context
    public MyService myService() {
        return new MyServiceImpl();
    }

    @Bean
    public DataSource dataSource() {
        return new DriverManagerDataSource("jdbc:h2:mem:testdb", "sa", "");
    }

    @Bean
    public JdbcTemplate jdbcTemplate(DataSource dataSource) { // Внедрение зависимости
        return new JdbcTemplate(dataSource);
    }
}

Видишь? @Bean на метод — и всё, пончик готов. Хочешь DataSource? На, получай. А вот этот JdbcTemplate — смотри, какая хитрая жопа — он сам себе в параметры DataSource просит. Spring глянет и скажет: «А, ну так у меня же такой бин есть, ёпта! Держи, на!» Автоматом заинжектит. Красота, в рот меня чих-пых!

А главное-то что? Если ты в названии класса или метода накосячил — компилятор тебя ещё на этапе написания ебанёт по рукам! Не то что в XML, где ошибка всплывет только когда приложение уже в продакшене накроется медным тазом.

Ну и, конечно, гибкость — овердохуища. Захотел — в методе if напиши, захотел — for цикл. Любую логику воткнуть можно. А ещё эти ваши условные штуки — @Profile, @ConditionalOnProperty. Типа, «создай этот бин, только если в настройках свойство app.mode=prod». Удобно, блядь!

И если конфигов дохуя, их можно импортить, как модули лего.

@Configuration
@Import({DatabaseConfig.class, SecurityConfig.class}) // Импорт других @Configuration классов
@ComponentScan("com.example.services") // Сканирование пакетов на наличие @Component
public class MainConfig {
}

Вот так, одной аннотацией @Import говоришь: «Подтяни-ка сюда, дружок, ещё парочку конфигов». И всё собирается, как надо. @ComponentScan — это вообще магия, он сам по пакетам побежит и всё, что помечено @Component, @Service, в контекст запихнёт.

Короче, после XML это как перейти с гужевой повозки на реактивный самолёт. Одно удовольствие, ёбана!