2016-10-10 69 views
1

我一直在为Spring Batch使用Xml配置,并感觉它更简单和简洁。但是,现在,人们建议使用javaconfig over xml。我搜索了这个话题。SpringBatch - javaconfig vs 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. 在一个框架中,您经常有要求 库的用户必须履行,以使所有的工作,例如需要一个数据源,一个 PlatformTransactionManager和一个线程池。从框架的角度来看,实施 并不重要,他们只需要 即可。在XML中,你必须为框架的 用户编写一些文档,告诉他们他们需要将这个和这个Spring bean以及这个名称添加到ApplicationContext中。在Java 中,您只需编写一个描述该合同的接口,并且使用该库的人员将实现该接口并将其作为 配置类添加到ApplicationContext中。这就是我用界面做的 。

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

选择XML在javaconfig

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

我得出的结论是个XML仍然可以使用,如果要创建独立的批处理作业,如果你没有用Spring Batch的整合创建任何新的框架。

我错过了xml的缺点吗?

回答

1

让我补充一些关于该主题的其他想法。

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

我对你为什么选择通过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()); 
} 

最后,我想这也是一个问题。我在spring批处理的上下文中使用了xml配置超过5年。两年前,我们完全转而使用javaconfig而不是xml。说实话,我还没有找到一个单一的理由,为什么我应该回去使用XML。不过,这是我的“品味问题”。