Под ботинком — весенний ботинок

Помните времена, когда нам приходилось регистрировать диспетчеров, viewResolvers и т. Д., Чтобы сделать наше весеннее веб-приложение? Тогда была @EnableWebMvcаннотация, и теперь даже это излишне.

В настоящее время единственное, что вам нужно сделать, это добавить org.springframework.boot:spring-boot-starter-webзависимость к вашему проекту, а все остальное делается автоматически.

То же самое касается подключения к базе данных. Не так давно минимальная конфигурация Spring-контекста с учетом БД была:

• Зарегистрировать источник данных ( <jdbc:embedded-database id="dataSource" type="HSQL"/>)
• Регистрация менеджера сущностей (через фабрику менеджеров сущностей) ( <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">)
• Зарегистрировать менеджер транзакций ( <bean id="transactionManager" class="org.springframework.orm.jpa.JpaTransactionManager" >)
• Возврат по границам транзакций на основе аннотаций ( <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="false"/>)

По ходу дела мы отбросили конфиги XML в пользу конфигураций. Теперь все, что вам нужно сделать, это добавить еще одну зависимость org.springframework.boot:spring-boot-starter-data-jpaи некоторый драйвер БД (например com.h2database:h2) и — опять же, Spring создает все за кулисами.

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

Высокий уровень просмотра

Основной механизм выглядит так:

Все волшебные бины регистрируются в Spring-конфигурациях ( @Configuration).
Но они загружаются только при соблюдении определенных условий, а именно:

• Обязательный класс доступен на пути к классам (новые бины волшебным образом создаются при добавлении зависимости).
• Требуемый компонент не был явно создан программистом.

Например, для загрузки, WebMvcAutoConfigurationкогда Servlet, DispatcherServletи  WebMvcConfigurerAdapterклассы находятся в пути к классам, тогда  @ConditionalOnClass({ Servlet.class, DispatcherServlet.class, WebMvcConfigurerAdapter.class })используется.

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

Так, например, для проверки, если defaultViewResolver()должен быть создан,  @ConditionalOnMissingBean(InternalResourceViewResolver.class)используется.

@Configuration
@ConditionalOnWebApplication
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class,
        WebMvcConfigurerAdapter.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
(...)
public class WebMvcAutoConfiguration {
    (...)

    @Bean
    @ConditionalOnMissingBean(InternalResourceViewResolver.class)
    public InternalResourceViewResolver defaultViewResolver() {
        InternalResourceViewResolver resolver = new InternalResourceViewResolver();
        resolver.setPrefix(this.prefix);
        resolver.setSuffix(this.suffix);
        return resolver;
    }

    (...)
}

@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication application = new SpringApplication(Application.class);
        application.run(args);
    }
}