SpringBatch - javaconfig vs xml

Question

Я использую Xml-конфигурацию для Spring Batch некоторое время и чувствую, что это проще и кратким. Однако в настоящее время люди предлагают использовать javaconfig над xml. Я искал эту тему.

Этот сайт рассказывает нам, почему javaconfig лучше всего https://blog.codecentric.de/en/2013/06/spring-batch-2-2-javaconfig-part-1-a-comparison-to-xml/

Лучшие причины, чтобы выбрать javaconfig над XML:

1. Мы хотим сделать некоторые основные конфигурации в рамках. Люди добавляют зависимости от нашей библиотеки фреймов и импортируют эти конфигурации в соответствии с их потребностями. Если эти конфигурации были написаны в XML, им было бы трудно открыть их до посмотреть, что они делают. На Java нет проблем.
2. В XML нет навигации. Это может быть хорошо, если у вас не слишком много XML-файлов, и все они находятся в вашей рабочей области, , потому что тогда вы можете воспользоваться поддержкой Spring IDE. Но базовую библиотеку обычно не следует добавлять в качестве проекта в рабочее пространство . При использовании конфигурации на основе Java вы можете отлично переходить в классы конфигурации каркаса . Я расскажу больше о этой теме в следующем сообщении в блоге.
3. В рамках, в которых у вас часто бывают требования пользователь библиотеки должен выполнить, чтобы сделать все, Работа, например, необходимость в DataSource, PlatformTransactionManager и пул потоков. Реализация не имеет значения с точки зрения структуры, им просто нужно, чтобы там было . В XML вы должны написать некоторую документацию для пользователей фреймворка , сообщая им, что им нужно добавить это и это, и этот весенний боб под этим именем в ApplicationContext. В Java вы просто пишете интерфейс, описывающий этот контракт, и люди , используя библиотеку, реализующую этот интерфейс, и добавьте его в качестве класса конфигурации в ApplicationContext. Вот что я сделал с интерфейсом.

Этот сайт рассказывает нам, почему XML лучше всего https://dzone.com/articles/consider-replacing-spring-xml

Лучшие причины, чтобы выбрать XML над javaconfig

1. Конфигурация централизована, это не рассеиваются среди всех различных компонентов, так что вы можете иметь хороший обзор бобов и их проводки в одном месте.
2. Если вам нужно разделить файлы, нет проблем, Spring позволит вам это сделать. Затем он собирает их во время выполнения через внутренние теги или агрегирование внешних контекстных файлов.
3. Только конфигурация XML позволяет осуществлять явную проводку - в отличие от автоподключения. Иногда последний слишком волшебный для моего собственного вкуса. Его кажущаяся простота скрывает реальную сложность: нам нужно не только переключаться между автопилотом по типу и по имени, но, что более важно, стратегия выбора соответствующего компонента среди всех подходящих побегов, но более опытных разработчиков Spring. Профили, похоже, делают это проще, но относительно новы и известны немногим.
4. И последнее, но не менее важное: XML полностью ортогонален файлу Java: между ними нет связи, поэтому класс может использоваться в нескольких контекстах с различными конфигурациями.

Я пришел к выводу, что XMLs все еще можно использовать, если вы создаете автономные пакетные задания, и если вы не создаете какие-либо новые структуры за счетом интеграции с Spring Batch.

Любые недостатки xmls, которые я пропускаю?

Answer 1

Позвольте мне добавить пару дополнительных мыслей по этой теме.

Что мне действительно нравится при использовании javaconfig - это возможность динамически создавать ваши вакансии. Например, у вас может быть входной параметр с именами файлов, а затем создать задание, которое выполняет чтение и обработку этих файлов параллельно, создавая шаг для каждого полученного имени файла. (используя MultiResourceItemReader будет делать это последовательно). Кроме того, в зависимости от входного параметра вы также можете определить поток задания по-разному.

Мои мысли о ваших причинах, почему вы выбираете xml над javaconfig: пункт 1: на мой взгляд это на самом деле не считается. У вас могут быть свои собственные классы конфигурации, вы можете определить свои собственные пакеты. Вы могли бы даже поместить их в собственные модули. Это всего лишь вопрос, как вы организуете свой код.

пункт 2: снова, это не считается также. Вы можете разделить свою конфигурацию на столько классов, сколько хотите. Вы можете использовать аннотацию @Import и @ContextScan, чтобы интегрировать то, что вы хотите в свой контекст.

пункт 3: автоуправление также может быть очень явно, если вы делаете это по классу, а не по интерфейсу. Кроме того, вы также можете напрямую вызвать метод, аннотированный с помощью @Bean. Пример:

@Configuration 
public MyBeanFactory { 
    @Bean 
    public MyBeanInterface bean1() { 
     return ...; 
    } 

    @Bean 
    public MyBeanInterface bean2() { 
     return ...; 
    } 
} 

@Component 
public MyBeanuser { 

    @Autowired 
    private MyBeanFactory beanFactory; 

    @PostConstruct 
    public void afterPropertiesSet() { 
    // this will actually set the bean that was created an registered in the 
    // spring context and not simply call the the method and create a new 
    // instance. So this wiring is very explicitly 
    setProperty1(beanFactory.bean1()); 
    setProperty2(beanFactory.bean2()); 
} 

В конце концов, я думаю, это также вопрос вкуса. Я использовал xml-конфигурацию более 5 лет в контексте весенней партии. Два года назад мы полностью переключились на использование javaconfig вместо xml. И, честно говоря, я не нашел единственной причины, по которой мне хотелось бы вернуться к использованию xml. Однако это мой «вопрос вкуса».