Spring Batch - java 配置与 xml

我已经使用 Spring Batch 的 Xml 配置一段时间了，感觉它更简单、简洁。然而，如今，人们建议使用 javaconfig 而不是 xml。我用谷歌搜索了这个话题。

这个网站告诉我们为什么 javaconfig 更好https://blog.codecentric.de/en/2013/06/spring-batch-2-2-javaconfig-part-1-a-comparison-to-xml/ 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. 在框架中你经常有需求 图书馆的用户必须满足才能使一切 工作，例如需要一个数据源，一个 PlatformTransactionManager 和线程池。实施情况 从框架的角度来看并不重要，他们只需要 到那里。在 XML 中，您必须编写一些文档 框架的用户，告诉他们需要添加这个和这个以及 此 Spring bean 在此名称下添加到 ApplicationContext。爪哇语 你只需编写一个描述该合约的界面，然后人们 使用库实现该接口并将其添加为 ApplicationContext 的配置类。这就是我所做的 与接口。

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

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

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

我的结论是，如果您要创建独立的批处理作业并且不通过与 Spring Batch 集成来创建任何新框架，则仍然可以使用 xml。

我错过了 xml 的任何缺点吗？

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

使用 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());
 }

最后，我想这也是一个品味问题。我在 Spring Batch 的背景下使用 xml 配置已经超过 5 年了。两年前，我们完全改用 javaconfig 而不是 xml。老实说，我还没有找到任何一个理由让我想回去使用 xml。然而，这是我的“品味问题”。