Spring Batch - Java 配置与 xml

SpringBatch - javaconfig vs xml

使用Xml配置Spring批处理有一段时间了,感觉比较简洁。然而,如今,人们建议在 xml 上使用 javaconfig。我用谷歌搜索了这个主题。

这个站点告诉我们为什么 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 的配置时,您可以完美 跳转到框架配置 classes。我会更多地谈论 此主题在以下博客中 post.
  3. 在框架中你经常有需求 图书馆的用户必须履行才能使一切 工作,例如需要一个DataSource,一个 PlatformTransactionManager 和一个线程池。实施 从框架的角度来看并不重要,他们只需要 到那里。在 XML 你必须为 框架的用户,告诉他们他们需要添加这个和这个以及 这个 Spring 这个名字下的 bean 到 ApplicationContext。在 Java 您只需编写一个描述该合同的界面,然后人们 使用库实现该接口并将其添加为 配置 class 到 ApplicationContext。那就是我所做的 与界面。

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

选择 xml 而不是 javaconfig

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

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

我遗漏了 xml 的任何缺点?

让我再补充几点关于这个话题的想法。

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

我对您选择 xml 而不是 javaconfig 的原因的看法: 第 1 点:我认为这不算数。你可以有你自己的配置 classes,你可以定义你自己的包。您甚至可以将它们放在自己的模块中。这只是一个问题,你如何组织你的代码。

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

要点 3:自动装配也可以非常明确,如果您通过 class 而不是通过接口进行。另外,也可以直接调用@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 批处理的上下文中,我使用 xml-configuration 超过 5 年。两年前,我们完全改用 javaconfig 而不是 xml。老实说,我还没有找到一个我应该回去使用 xml 的理由。然而,这是我的"matter of taste"。