SpringBatch – javaconfig vs xml

我一直在为Spring Batch使用Xml配置,感觉它更简单和简洁。 但是,现在人们建议使用javaconfig而不是xml。 我用Google搜索了这个话题。

这个网站告诉我们为什么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中,你必须为框架的用户编写一些文档,告诉他们需要将这个以及这个以及此名称的Spring bean添加到ApplicationContext中。 在Java中,您只需编写一个描述该契约的接口,使用该库的人实现该接口并将其作为配置类添加到ApplicationContext。 这就是我对界面所做的。

这个网站告诉我们为什么xml更好https://dzone.com/articles/consider-replacing-spring-xml

选择xml而不是javaconfig的主要原因

  1. 配置是集中的,它不会分散在所有不同的组件中,因此您可以在一个地方对bean及其布线进行很好的概述。
  2. 如果您需要拆分文件,没问题,Spring会让您这样做。 然后,它在运行时通过内部标记或外部上下文文件聚合重新组合它们。
  3. 只有XML配置允许显式连接 – 而不是自动assembly。 有时,后者对我自己的品味来说有点太神奇了。 它显而易见的简单性隐藏了真正的复杂性:我们不仅需要在按类型和按名称自动assembly之间切换,更重要的是,在所有符合条件的版本中选择相关bean的策略可以逃脱,但是经验丰富的Spring开发人员。 配置文件似乎使这更容易,但相对较新,并为少数人所知。
  4. 最后但并非最不重要的是,XML与Java文件完全正交:2之间没有耦合,因此该类可以在具有不同配置的多个上下文中使用。

我总结说,如果您正在创建独立的批处理作业,并且您没有通过与Spring Batch集成来创建任何新框架,那么仍然可以使用xmls。

我错过了xmls的任何缺点吗?

让我在这个主题上添加一些额外的想法。

使用javaconfig时我真正喜欢的是能够动态创建作业。 例如,您可以使用带有文件名的输入参数,然后通过为每个接收的文件名创建一个步骤来创建一个并行执行读取和处理此文件的作业。 (使用MultiResourceItemReader将按顺序执行此操作)。 此外,根据inputparameter,您还可以以不同方式定义作业流。

我想你为什么选择xml而不是javaconfig:第1点:这在我看来并不重要。 您可以拥有自己的配置类,也可以定义自己的包。 你甚至可以将它们放在自己的模块中。 这只是一个问题,您如何组织代码。

第2点:再次,这也不算数。 您可以根据需要在多个类中拆分配置。 您可以使用@Import和@ContextScan注释将您想要的内容集成到上下文中。

第3点:自动assembly也可以非常明确,如果你是按类而不是通过接口来实现的。 此外,您还可以直接调用@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-configuration超过5年。 两年前,我们完全转而使用javaconfig而不是xml。 老实说,我还没有找到一个我应该回去使用xml的原因。 然而,这是我的“品味问题”。