Spring @Configuration 클래스 이해

Spring @Configuration 클래스 이해

---

Spring @Autowired 사용법 이해 라는 질문에 따라 스프링 와이어 링의 다른 옵션 인 @Configuration클래스에 대한 완전한 지식 기반을 만들고 싶었습니다 .

다음과 같은 스프링 XML 파일이 있다고 가정 해 보겠습니다.

<?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>

@Configuration대신 어떻게 사용할 수 있습니까? 코드 자체에 영향을 미칩니 까?

---

XML 마이그레이션 @Configuration

@Configuration몇 단계 를 거쳐 xml을로 마이그레이션 할 수 있습니다 .

1. @Configuration주석이 달린 클래스를 만듭니다 .

   @Configuration
   public class MyApplicationContext {
   
   }
   

2. 각 <bean>태그에 대해 다음 과 @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. 수입하기 위해 beanFromSomewhereElse우리는 정의를 가져와야합니다. XML로 정의 할 수 있으며 다음을 사용할 것입니다 @ImportResource.

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

   Bean이 다른 @Configuration클래스에 정의되어 있으면 @Import주석을 사용할 수 있습니다 .

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

4. After we imported other XMLs or @Configuration classes, we can use the beans they declare in our context by declaring a private member to the @Configuration class as follows:

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

   Or use it directly as parameter in the method which defines the bean that depends on this beanFromSomewhereElse using @Qualifier as follows:

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

5. Importing properties is very similar to importing bean from another xml or @Configuration class. Instead of using @Qualifier we'll use @Value with properties as follows:

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

   This can be used with SpEL expressions as well.

6. In order to allow spring to treat such classes as beans containers we need to mark this in our main xml by putting this tag in the context:

   <context:annotation-config/>
   

   You can now import @Configuration classes exactly the same as you would create a simple bean:

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

   There are ways to avoid spring XMLs altogether but they are not in the scope of this answer. You can find out one of these options in my blog post on which I'm basing my answer.

---

The advantages and disadvantages of using this method

Basically I find this method of declaring beans much more comfortable than using XMLs due to a few advantages I see:

1. Typos - @Configuration classes are compiled and typos just won't allow compilations
2. Fail fast (compile time) - If you forget to inject a bean you'll fail on compile time and not on run-time as with XMLs
3. Easier to navigate in IDE - between constructors of beans to understand the dependency tree.
4. Possible to easily debug configuration startup

The disadvantages are not many as I see them but there are a few which I could think of:

1. Abuse - Code is easier to abuse than XMLs
2. With XMLs you can define dependencies based on classes that are not available during compile time but are provided during run-time. With @Configuration classes you must have the classes available at compile time. Usually that's not an issue, but there are cases it may be.

Bottom line: It is perfectly fine to combine XMLs, @Configuration and annotations in your application context. Spring doesn't care about the method a bean was declared with.

참고URL : https://stackoverflow.com/questions/24014919/understanding-spring-configuration-class