SpringBatch - javaconfig vs xml [英] SpringBatch - javaconfig vs xml

查看:204
本文介绍了SpringBatch - javaconfig vs xml的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I have been using Xml configuration for Spring Batch for a while, and feel it is simpler and concise. However, nowadays, people are suggesting to use javaconfig over xml. I googled this topic.

这个网站告诉我们为什么javaconfig更好 https://blog.codecentric.de/en/2013/06/spring-batch-2- 2-javaconfig-part-1-a-comparison-to-xml /

This site tells us why javaconfig is better 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

This site tells us why xml is better https://dzone.com/articles/consider-replacing-spring-xml

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


  1. 配置是集中的,不是分散在所有不同的组件中,这样你就可以在一个地方对bean和它们的布线进行很好的概述。

  2. 如果你需要拆分你的文件,没问题,Spring让你这样做。然后,它通过内部标记或外部上下文文件聚合在运行时重新组合它们。

  3. 只有XML配置允许显式连接 - 而不是自动装配。有时,后者对我自己的品味来说有点太神奇了。它显而易见的简单性隐藏了真正的复杂性:我们不仅需要在按类型和按名称自动装配之间切换,更重要的是,在所有符合条件的版本中选择相关bean的策略可以逃脱,但是经验丰富的Spring开发人员。配置文件似乎使这更容易,但相对较新,并且很少有人知道。

  4. 最后但并非最不重要的是,XML与Java文件完全正交:2之间没有耦合,所以该类可以在不止一个具有不同配置的上下文中使用。

  1. Configuration is centralized, it’s not scattered among all different components so you can have a nice overview of beans and their wirings in a single place.
  2. If you need to split your files, no problem, Spring let you do that. It then reassembles them at runtime through internal tags or external context files aggregation.
  3. Only XML configuration allows for explicit wiring – as opposed to autowiring. Sometimes, the latter is a bit too magical for my own taste. Its apparent simplicity hides real complexity: not only do we need to switch between by-type and by-name autowiring, but more importantly, the strategy for choosing the relevant bean among all eligible ones escapes but the more seasoned Spring developers. Profiles seem to make this easier, but is relatively new and is known to few.
  4. Last but not least, XML is completely orthogonal to the Java file: there’s no coupling between the 2 so that the class can be used in more than one context with different configurations.

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

xmls的任何缺点我都是错过了?

推荐答案

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

Let me add a couple of additional thoughts on the topic.

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

What I really like when using javaconfig is the ability to create your jobs dynamically. E.g., you could have an inputparameter with filenames and then create a job that executes reading and processing this files in parallel by creating a step for every received filename. (using a MultiResourceItemReader would do this sequentially). Moreover, depending on inputparameter, you could also define the job flow differently.

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

My thoughts on your reasons why choosing xml over javaconfig: point 1: this doesn't really count in my opinion. You can have your own configuration classes, you can define your own packages. You could even put them in own modules. This is just a matter, how you organize your code.

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

point 2: again, this doesn't count as well. You can split your configuration in as many classes as you'd like. You can use the @Import and @ContextScan annotation in order to integrate what you want into your context.

第3点:自动装配也可以非常明确,如果你这样做按类而不是按界面。此外,您还可以直接调用@Bean注释的方法。例如:

point 3: autowiring can also be very explicitly, if you do it by class and not by interface. Moreover, you can also call directly the method annotated with @Bean. An example:

@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的原因。然而,这是我的品味问题。

In the end, I guess it is also a matter of taste. I was using xml-configuration for over 5 years in the context of spring batch. Two years ago, we completely switched to use javaconfig instead of xml. And honestly, I haven't found one single reason why I should want to go back to use xml. However, this is my "matter of taste".

这篇关于SpringBatch - javaconfig vs xml的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆