Question

我一直在为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的主要原因：

我们想在框架中做一些基本配置。人们补充道依赖于我们的框架库并导入它们根据需要配置。如果这些配置用XML编写，他们很难打开它们看看他们在做什么。在Java中没问题。
XML中没有导航功能。只要你，这可能没问题没有太多的XML文件，所有这些文件都在你的工作区中，因为那样你就可以利用Spring IDE的支持。但是一个框架库通常不应该作为项目添加到工作区。使用基于Java的配置时，您可以完美无缺跳转到框架配置类。我会谈谈更多以下博客文章中的这个主题。
在一个框架中，您经常有要求图书馆的用户必须完成才能完成所有事情工作，例如需要一个DataSource，a PlatformTransactionManager和一个线程池。实施从框架的角度来看无关紧要，他们只需要到那里。在XML中，你必须为它写一些文档框架的用户，告诉他们他们需要添加这个和这个这个Spring bean以这个名字命名为ApplicationContext。在Java中你只需要写一个描述合同的界面和人使用库实现该接口并将其添加为 ApplicationContext的配置类。这就是我做的用界面。

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

选择xml而非javaconfig的主要原因

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

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

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

Answer 1

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

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

我对你在javaconfig上选择xml的原因的看法：第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-configuration超过5年。两年前，我们完全转而使用javaconfig而不是xml。老实说，我还没有找到一个我应该回去使用xml的原因。然而，这是我的“品味问题”。

SpringBatch - javaconfig vs xml

1 个答案: