스프링 컨테이너와 스프링 빈

김영한 강사님의 스프링 핵심 원리 - 기본편 수강 후 정리한 포스팅입니다.

 

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

 

1. 스프링 컨테이너 생성

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext 를 스프링 컨테이너라 부른다. 

기존에는 개발자가 AppConfig(예시) class 를 사용하여 직접 객체를 생성하고 DI 까지 했지만, ApplicationContext 를 통해 스프링 컨테이너로 스프링 빈 객체를 찾고 DI 까지 한다.

위 코드에서 AnnotationConfigApplicationContext() 라는 구현체를 통해 스프링 컨테이너를 만들고, 컨테이너를 생성할 때는 구성 정보를 지정해주어야한다. 여기서는 AppConfig.class 를 구성정보로 지정한다.

 

잠시 AppConfig.class 를 살펴보자

@Bean 어노테이션을 사용해 빈으로 등록할 객체를 표시하고 있다. 스프링 컨테이너의 구성정보로 AppConfig.class 를 지정하면, @Bean 으로 지정된 객체들이 스프링 빈으로 등록된다.

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public DiscountPolicy discountPolicy() {
        return new RateDiscountPolicy();
    }
}

* 스프링은 빈을 생성하고 의존관계를 주입하는 단계가 나누어져 있다.

 

 

스프링 빈은 무엇인가?

Spring Container 가 관리하는 자바 객체를 Bean 이라 부른다.

위 코드에서 AnnotationConfigApplicationContext() 라는 구현체를 통해 스프링 컨테이너를 만든다.

 

2. 스프링 빈 조회

위 그림에서 빈 이름에 서로 다른 4가지  빈이 등록된 것을 볼 수 있다. 각각의 빈의 타입은 MemberService, OrderService, MemberRepository, DiscountPolicy 이다. 만약 이름은 다르지만 동일한 타입의 빈이 등록되면 어떻게 될까?

NoUniqueBeanDefinitionException 이라는 예외가 발생한다. 그렇다면 동일한 타입의 빈은 2개 이상 존재할 수 없는 것일까?

그렇지 않다. 위 그림에서 빈 이름 컬럼이 있듯이, 각자의 빈은 서로 다른 객체이기에 이름을 지정하여 개별로 존재할 수 있다.

 

 

3. 스프링 빈 상속 관계

스프링에선  부모타입으로 빈을 조회하면 자식 타입도 함께 조회된다.

그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면, 모든 스프링 빈을 조회한다.

 

public class ApplicationContextExtendsFindTest {
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestConfig.class);
 
    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 중복 오류가 발생한다")
    void findBeanByParentTypeDuplicate(){
        Assertions.assertThrows(NoUniqueBeanDefinitionException.class, () -> ac.getBean(DiscountPolicy.class));
    }
 
 
    @Test
    @DisplayName("부모 타입으로 조회시, 자식이 둘 이상 있으면, 빈 이름을 지정하면 된다.")
    void findBeanByParentTypeBeanName(){
        RateDiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy", RateDiscountPolicy.class);
        assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
    }
 
    @Test
    @DisplayName("부모 타입으로 모두 조회하기")
    void findAllBeanByParentType() {
        Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
        assertThat(beansOfType.size()).isEqualTo(2);
 
        // 실제 테스트코드 작성할 때는 이렇게 반복문이나 println 은 남겨두는 것은 적절하지 않다. 테스트 시스템이 판별하게 해야하지, 아래 같은 반복문은 사람의 눈으로 확인하는 것이기 때문.
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
    }
 
    @Test
    @DisplayName("부모 타입으로 모두 조회하기 - Object")
    void findAllBeanByObjectType() {
        Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
    // 위에서 테스트한 빈은 물론, spring 에 있는 빈까지 모두 튀어나온다. => java 는 모든게 Object 를 상속받기 때문.        
    }  
 
      // AppConfig.class 수정 대신, 임시 config 클래스 작성
    @Configuration
    static class TestConfig {
        @Bean
        public DiscountPolicy rateDiscountPolicy() {
            return new RateDiscountPolicy();
        }
 
        @Bean
        public DiscountPolicy fixDiscountPolicy() {
            return new FixDiscountPolicy();
        }
    }
}

실제 어플리케이션을 개발할 땐, 이런 식으로 ApplicationContext  로 빈을 조회할 일은 거의 없지만, 부모 타입으로 조회할 때 어디까지 조회되는지 등의 내용은 기본적으로 숙지해야 하는 개념이다.

 

 

4. BeanFactory 와 ApplicationContext

앞서 ApplicationContext 가 스프링 컨테이너라 소개했는데, ApplicationContext 도 결국은 인터페이스며 동시에 BeanFactory 라는 인터페이스를 상속받고 있다. 

 

[ BeanFactory ]

스프링 컨테이너의 최상위 인터페이스다.
스프링 빈을 관리하고 조회하는 역할을 담당한다. ( getBean() 을 제공 )
지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다. 

BeanFactory 를 직접 사용할 일은 거의 없고, 대신 부가기능이 포함된 ApplicationContext 를 사용한다.

 

[ ApplicationContext ]

BeanFactory 기능을 모두 상속받아서 제공한다.

빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까?
애플리케이션을 개발할 때는 빈은 관리하고 조회하는 기능은 물론이고, 수 많은 부가기능이 필요하다. 

그 중에는 메시지 소스를 활용한 국제화 기능 , 환경변수, 어플리케이션 이벤트 , 편리한 리소스 조회 등의 다양한 부가기능이 존재한다.

 

BeanFactory 나 ApplicationContext 모두 스프링 컨테이너라 부른다.

 

 

5. 스프링 빈 설정 메타 정보 - BeanDefinition

스프링의 설정 형식에는 xml 파일을 사용하는 방법과 동시에 자바 코드를 이용하는 방식이 존재한다.

어떻게 이런 다양한 설정 형식을 지원할 수 있을까? 그 중심에는 BeanDefinition 이라는 추상화가 존재한다.

즉 역할과 구현을 개념적으로 나눈 것이다.

Annotated 라는 부분은, 어노테이션을 통해 빈을 생성한 것으로 @Bean 을 사용한 것이라 생각하면 된다.

그 다음에 나오는 Xml 부분은 Xml  파일로 스프링 빈을 설정한 형식을 나타낸다. 

마찬가지로 새로운 형식의 설정 정보가 추가되면(어노테이션도, xml 도 아닌) XxxBeanDefinitionReader 를 만들어 BeanDefinition 을 생성하면 된다.