Где уместнее использовать XML конфигурацию, а не Java или гибридную конфигурации?

# Когда XML конфигурация уместнее других подходов

XML конфигурация в Spring — это наследие из нулевых, но она остаётся актуальной в специфичных сценариях:

1. Крупные распределённые проекты с фиксированной архитектурой

В больших корпоративных системах, где:

• Конфигурация отделена от кода — бизнес хочет, чтобы ops-команда изменяла параметры БД, API endpoints без пересборки артефактов
• Множество окружений — dev, staging, prod могут иметь радикально отличающиеся бины

XML позволяет:

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource">
  <property name="jdbcUrl" value="${DB_URL}" />
  <property name="username" value="${DB_USER}" />
</bean>

Без пересборки приложения — просто измени XML и перезагрузи контекст.

2. Легаси-системы, где рефакторинг невозможен

Если приложение:

• Написано в эру Spring 3.x, когда аннотации были примитивными
• Имеет тысячи строк XML с годами оптимизаций
• Требует стабильности больше, чем инноваций

Попытка мигрировать на Java Config или аннотации может привести к регрессиям. XML конфигурация работает, и люди её понимают.

3. Интеграция с внешними legacy-библиотеками

Старомодные библиотеки часто ожидают XML Spring конфигурацию:

<bean id="jaxbContext" 
      class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
  <property name="classesToBeBound">
    <list>
      <value>com.example.LegacyXmlModel</value>
    </list>
  </property>
</bean>

Заменить такое на Java Config часто означает переписать интеграцию полностью.

4. Сложная вложенная структура бинов и их зависимостей

Для очень сложного графа зависимостей XML иногда более читаемой, чем множество @Configuration классов:

<bean id="serviceA" class="com.example.ServiceA">
  <constructor-arg ref="serviceB" />
  <constructor-arg ref="serviceC" />
</bean>

vs Java Config с @Bean методами — если их 50+, читаемость падает.

5. Динамическая генерация конфигураций

Когда конфигурация не статична и генерируется во время запуска (крайне редко):

ApplicationContext context = new ClassPathXmlApplicationContext(
  generateXmlConfigDynamically()
);

Определение бинов через аннотации или Java Config требует рефлексии.

Сравнение подходов

Рекомендация для новых проектов

Выбирай гибридный подход:

1. Основная конфигурация — Java Config с @Configuration
2. Экспортируемые параметры — @ConfigurationProperties для environment variables
3. Legacy интеграции — XML импортируй через @ImportResource

@Configuration
@ImportResource("classpath:legacy-beans.xml")
@EnableConfigurationProperties(AppProperties.class)
public class AppConfig {
  
  @Bean
  public DataSource dataSource(AppProperties props) {
    // Java Config с параметрами из properties
  }
}

Этот подход:

• Позволяет постепенно отходить от XML
• Сохраняет совместимость с legacy-кодом
• Даёт максимальную гибкость

Итог

XML конфигурация не мертва — она уместна в корпоративных системах, легаси-приложениях и случаях, когда разделение конфигурации от кода критично. Но для новых зелёных проектов Java Config + аннотации — стандарт индустрии.