Spring-XML-Datei in Spring @Configuration-class konvertieren

Nach der Frage, warum Spring @Autowired verwendet werden soll, wollte ich eine komplette Wissensbasis für die andere Option der @Configuration , die @Configuration class, @Configuration .

Angenommen, ich habe eine Quell-XML-Datei, die wie folgt aussieht:

            

Wie kann ich stattdessen @Configuration verwenden? Hat es Auswirkungen auf den Code selbst?

(Haftungsausschluss – diese Antwort basiert auf meinem Blogpost )

@Configuration XML zu @Configuration

Es ist möglich, das XML in wenigen Schritten in eine @Configuration zu migrieren:

  1. Erstellen Sie eine annotierte class @Configuration :

     @Configuration public class MyApplicationContext { } 
  2. Erstellen Sie für jedes @Bean -Tag eine mit @Bean annotierte @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. Um beanFromSomewhereElse zu importieren, beanFromSomewhereElse wir seine Definition importieren. Es kann in einem XML definiert werden und wir verwenden @ImportResource :

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

    Wenn die Bean in einer anderen @Configuration class definiert ist, können wir die @Import Annotation verwenden:

     @Import(OtherConfiguration.class) @Configuration public class MyApplicationContext { ... } 
  4. Nachdem wir andere XMLs oder @Configuration classn importiert haben, können wir die Beans verwenden, die sie in unserem Kontext deklarieren, indem @Configuration wie folgt ein privates Member für die @Configuration class deklarieren:

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

    Oder verwenden Sie es direkt als Parameter in der Methode, die die Bean definiert, die von dieser beanFromSomewhereElse mit @Qualifier wie folgt abhängt:

     @Bean(name = "anotherBean") public AnotherClass getAnotherClass(@Qualifier (value = "beanFromSomewhereElse") final StrangeBean beanFromSomewhereElse) { return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse); } 
  5. Das Importieren von Eigenschaften ist dem Importieren von Bean aus einer anderen @Configuration oder @Configuration class sehr ähnlich. Anstatt @Qualifier wir @Value mit den folgenden Eigenschaften:

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

    Dies kann auch mit SpEL- Ausdrücken verwendet werden.

  6. Damit Spring classn wie Beans-Container behandeln kann, müssen wir dies in unserem Haupt-XML-Code markieren, indem wir dieses Tag in den Kontext einfügen:

      

    Sie können jetzt @Configuration classn genau so importieren, wie Sie eine einfache Bean erstellen würden:

      

    Es gibt Möglichkeiten, Quell-XMLs vollständig zu vermeiden, aber sie sind nicht Gegenstand dieser Antwort. Sie können eine dieser Optionen in meinem Blogpost herausfinden, auf dem ich meine Antwort gründe.


Die Vor- und Nachteile der Verwendung dieser Methode

Grundsätzlich finde ich diese Methode, Bohnen zu deklarieren, viel bequemer als die Verwendung von XMLs aufgrund einiger Vorteile, die ich sehe:

  1. Tipperrors – @Configuration classn werden kompiliert und Tipperrors erlauben keine Kompilationen
  2. Fail Fasten (Kompilierzeit) – Wenn Sie vergessen, eine Bean zu injizieren, scheitern Sie bei der Kompilierung und nicht bei der Laufzeit wie bei XMLs
  3. Einfachere Navigation in IDE – zwischen Konstruktoren von Beans, um den Abhängigkeitsbaum zu verstehen.
  4. Möglich, den Konfigurationsstart leicht zu debuggen

Die Nachteile sind nicht viele, wie ich sie sehe, aber es gibt einige, an die ich denken könnte:

  1. Missbrauch – Code ist einfacher zu missbrauchen als XMLs
  2. Mit XMLs können Abhängigkeiten basierend auf classn definiert werden, die während der Kompilierungszeit nicht zur Verfügung stehen, aber zur Laufzeit bereitgestellt werden. Bei @Configuration classn müssen die classn zum Zeitpunkt der Kompilierung verfügbar sein. Normalerweise ist das kein Problem, aber es kann Fälle geben.

Fazit: Es ist vollkommen in Ordnung, XMLs, @Configuration und Annotationen in Ihrem Anwendungskontext zu kombinieren. Spring interessiert sich nicht für die Methode, mit der eine Bean deklariert wurde.