Что такое XML-конфигурация в Spring? Каковы её плюсы и минусы?

XML-конфигурация в Spring — это декларативный способ определения Spring-бинов и их зависимостей через XML-файлы (например, applicationContext.xml). Это был основной метод до появления аннотаций.

Пример конфигурации бина:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans.xsd">

    <!-- Определение бина сервиса -->
    <bean id="userService" class="com.example.service.UserServiceImpl">
        <!-- Внедрение зависимости через сеттер -->
        <property name="userRepository" ref="userRepository"/>
    </bean>

    <!-- Определение бина репозитория -->
    <bean id="userRepository" class="com.example.repository.JdbcUserRepository">
        <property name="dataSource" ref="dataSource"/>
    </bean>

    <bean id="dataSource" class="org.apache.commons.dbcp2.BasicDataSource">
        <property name="url" value="jdbc:h2:mem:testdb"/>
    </bean>
</beans>

Преимущества:

• Централизация: Вся конфигурация в одном/нескольких файлах, что упрощает обзор.
• Отделение кода от конфигурации: Можно менять зависимости, не перекомпилируя код.
• Гибкость: Позволяет легко конфигурировать бины, классы которых находятся вне вашего кода (сторонние библиотеки).
• Историческое значение: Ключево для поддержки legacy-проектов.

Недостатки:

• Многословность: Большой объем XML-кода.
• Слабая безопасность типов: Ошибки в именах классов или свойств обнаруживаются только во время выполнения (Runtime), а не компиляции.
• Менее удобный рефакторинг: IDE сложнее автоматически переименовывать ссылки в XML.

Современные альтернативы:

1. Конфигурация на аннотациях: Использование @Component, @Service, @Autowired, @Configuration, @Bean.
2. Java-based конфигурация: Определение бинов в классах с аннотацией @Configuration.

XML сейчас используется реже, но его понимание необходимо для работы со старыми кодобазами и в некоторых специфичных сценариях (например, конфигурация AOP).