2016-10-10 54 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。不過,這是我的「品味問題」。