Zrozumienie klasy Spring @Configuration

Idąc za pytaniem Zrozumieć użycie Spring @Autowired , chciałem stworzyć kompletną bazę wiedzy na temat innej opcji okablowania sprężynowego, @Configurationklasy.

Załóżmy, że mam wiosenny plik XML, który wygląda następująco:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

  <import resource="another-application-context.xml"/>

  <bean id="someBean" class="stack.overflow.spring.configuration.SomeClassImpl">
    <constructor-arg value="${some.interesting.property}" />
  </bean>

  <bean id="anotherBean" class="stack.overflow.spring.configuration.AnotherClassImpl">
    <constructor-arg ref="someBean"/>
    <constructor-arg ref="beanFromSomewhereElse"/>
  </bean>
</beans>

Jak mogę @Configurationzamiast tego użyć ? Czy ma to wpływ na sam kod?

Migracja XML do @Configuration

Istnieje możliwość migracji xml do a @Configurationw kilku krokach:

1. Utwórz @Configurationzajęcia z adnotacjami:

   @Configuration
   public class MyApplicationContext {
   
   }

2. Dla każdego <bean>tagu utwórz metodę z adnotacją @Bean:

   @Configuration
   public class MyApplicationContext {
   
     @Bean(name = "someBean")
     public SomeClass getSomeClass() {
       return new SomeClassImpl(someInterestingProperty); // We still need to inject someInterestingProperty
     }
   
     @Bean(name = "anotherBean")
     public AnotherClass getAnotherClass() {
       return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse); // We still need to inject beanFromSomewhereElse
     }
   }

3. Aby zaimportować beanFromSomewhereElse, musimy zaimportować jego definicję. Można go zdefiniować w XML i użyjemy @ImportResource:

   @ImportResource("another-application-context.xml")
   @Configuration
   public class MyApplicationContext {
     ...  
   }

   Jeśli fasola jest zdefiniowana w innej @Configurationklasie, możemy użyć @Importadnotacji:

   @Import(OtherConfiguration.class)
   @Configuration
   public class MyApplicationContext {
     ...
   }

4. Po zaimportowaniu innych plików XML lub @Configurationklas możemy użyć fasoli, które zadeklarowały w naszym kontekście, deklarując prywatny element członkowski w @Configurationklasie w następujący sposób:

   @Autowired
   @Qualifier(value = "beanFromSomewhereElse")
   private final StrangeBean beanFromSomewhereElse;

   Lub użyj go bezpośrednio jako parametru w metodzie, która definiuje fasolę, która zależy od tego, beanFromSomewhereElseużywając @Qualifierw następujący sposób:

   @Bean(name = "anotherBean")
   public AnotherClass getAnotherClass(@Qualifier (value = "beanFromSomewhereElse") final StrangeBean beanFromSomewhereElse) {
     return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse);
   }

5. Importowanie właściwości jest bardzo podobne do importowania komponentu bean z innego pliku XML lub @Configurationklasy. Zamiast używać @Qualifier, użyjemy @Valuez właściwościami w następujący sposób:

   @Autowired
   @Value("${some.interesting.property}")
   private final String someInterestingProperty;

   Można tego używać również z wyrażeniami SpEL .

6. Aby umożliwić Springowi traktowanie takich klas jak pojemników na ziarna, musimy zaznaczyć to w naszym głównym pliku XML, umieszczając ten tag w kontekście:

   <context:annotation-config/>

   Możesz teraz importować @Configurationklasy dokładnie tak samo, jak utworzyłbyś prosty bean:

   <bean class="some.package.MyApplicationContext"/>

   Istnieją sposoby na całkowite uniknięcie sprężynowych plików XML, ale nie są one objęte zakresem tej odpowiedzi. Możesz dowiedzieć się o jednej z tych opcji w moim wpisie na blogu, na którym opieram swoją odpowiedź.

Zalety i wady stosowania tej metody

Zasadniczo uważam, że ta metoda deklarowania fasoli jest znacznie wygodniejsza niż używanie plików XML z powodu kilku zalet, które widzę:

1. Literówki - @Configurationklasy są kompilowane, a literówki po prostu nie pozwalają na kompilacje
2. Szybka awaria (czas kompilacji) - Jeśli zapomnisz wstrzyknąć komponent bean, zawiedziesz w czasie kompilacji, a nie w czasie wykonywania, jak w przypadku XML
3. Łatwiejsze poruszanie się w IDE - między konstruktorami fasoli, aby zrozumieć drzewo zależności.
4. Możliwość łatwego debugowania uruchamiania konfiguracji

Niedogodności jest niewiele, ale jest kilka, o których mógłbym pomyśleć:

1. Nadużycie - kod jest łatwiejszy do nadużycia niż pliki XML
2. Dzięki plikom XML można zdefiniować zależności na podstawie klas, które nie są dostępne w czasie kompilacji, ale są udostępniane w czasie wykonywania. W przypadku @Configurationklas musisz mieć klasy dostępne w czasie kompilacji. Zwykle nie stanowi to problemu, ale zdarzają się przypadki.

Podsumowując: łączenie plików XML @Configurationi adnotacji w kontekście aplikacji jest całkowicie w porządku . Wiosna nie dba o metodę zadeklarowania fasoli.