BeanFactory, BeanDefinition (+ 스프링 컨테이너 XML 설정)

# 스프링 컨테이너

스프링 컨테이너는 BeanFactory와 ApplicationContext를 구분한다고 했다. 이건 무슨 의미일까?

@ BeanFactory

• 스프링 컨테이너의 최상위 인터페이스이다.
• 스프링 빈을 관리하고 조회하는 역할을 담당한다.
• getBean() 인터페이스를 제공하여 등록된 빈을 조회할 수 있게 해준다.
• 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다.

 

@ ApplicationContext

BeanFactory의 기능을 모두 상속받아 제공한다. 그렇다면 굳이 BeanFactory와 ApplicationContext를 나눈 이유는 무엇일까? 그건 바로 어플리케이션을 개발할 때 빈을 관리하고 조회하는 기능과 더불어 수많은 부가기능이 필요하기 때문이다.

부가기능은 설명하면 정말 내용이 길어지니, 나중에 따로 설명하도록 하겠다.

• MessageSource : 메시지 소스를 활용한 국제화 기능(나라별 언어 설정)
• EnviromentCapable : 환경변수 기능, 로컬 - 개발 - 운영등을 구분하여 처리
• ApplicationEventPublisher : 앱 이벤트, 이벤트를 발행하고 구독하는 모델을 편리하게 지원
• ResourceLoader : 편리한 리소스 조회, 파일 - 클래스패스 - 외부등에서 리소스를 편리하게 조회

 

---

@ 결론

• ApplicationContext는 BeanFactory의 모든 기능을 상속받는다
• App..Context 는 BeanFactory의 빈 관리 기능 + 부가기능을 제공한다.
• BeanFactory를 직접 사용할 일은 없다고 보면 된다.
• BeanFactory나 App..Context 둘 다 스프링 컨테이너라고 부른다.

 

---

# 다양한 설정 형식 지원 - Java, XML

스프링 컨테이너는 다양한 형식의 설정정보를 받아드릴 수 있게 설계되어 있다. 보통은 Java 코드의 어노테이션(@)을 사용하지만 필요하다면 XML등 다른 방식을 사용해도 된다.

 

물론 스프링 부트가 나오며 어노테이션 방식 말고는 거의 사용하지 않지만, 옛 프로젝트의 레거시 코드는 XML로 작성된 경우가 종종 있으니 이런 방법이 있다는 것을 알아만 두고 넘어가도록 하자. 형식만 다를 뿐 설정방법은 비슷하다.

구현체를 바꾸면 XML로도 설정을 할 수 있다.

public class XmlAppContext {
    @Test
    void xmlAppContext() {
    	// AppConfig.java 객체 대신에 appConfig.xml를 등록해주면 된다.
        ApplicationContext ac = new
                GenericXmlApplicationContext("appConfig.xml");

        MemberService memberService = ac.getBean("memberService",
                MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

appConfig.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://">
    <bean id="memberService" class="hello.core.member.MemberServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository"/>
    </bean>
    <bean id="memberRepository"
          class="hello.core.member.MemoryMemberRepository"/>
    <bean id="orderService" class="hello.core.order.OrderServiceImpl">
        <constructor-arg name="memberRepository" ref="memberRepository"/>
        <constructor-arg name="discountPolicy" ref="discountPolicy"/>
    </bean>
    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy"/>
</beans>

 

---

# 스프링 빈 설정 메타 정보 - BeanDefinition

위에서 보는 것 처럼 스프링 설정은 자바, XML, Groovy등으로 구현체를 바꾸더라도 다른 코드를 변경할 필요가 없다. 스프링 컨테이너는 BeanDefinition에만 의존하도록 설계되어 있다. 즉, 내가 직접 BeanDefinition 구현체를 만들어 직접 정의 할 수 있다는 것이다. (물론 실제로 할 일은 거의 없다.)

우리가 @Bean 또는 와 같은 설정정보 하나당, 하나의 메타정보를 생성하여 BeanDefinition를 만든다. 스프링 컨테이너는 실제 설정 정보가 아닌 이 메타정보(BeanDefinition)만을 보고, 이를 기반으로 스프링 빈을 생성한다.

설정파일을 읽는건 BeanDefinitionReader 객체이다. 해당 객체는 BeanDefinition 객체를 만든다.

 

@ BeanDefinition 객체 필드

• BeanClassName: 생성할 빈의 클래스 명(자바 설정 처럼 팩토리 역할의 빈을 사용하면 없음)
• factoryBeanName: 팩토리 역할의 빈을 사용할 경우 이름, 예) appConfig
• factoryMethodName: 빈을 생성할 팩토리 메서드 지정, 예) memberService
• Scope: 싱글톤(기본값)
• lazyInit: 스프링 컨테이너를 생성할 때 빈을 생성하는 것이 아니라, 실제 빈을 사용할 때 까지 최대한
  생성을 지연처리 하는지 여부
• InitMethodName: 빈을 생성하고, 의존관계를 적용한 뒤에 호출되는 초기화 메서드 명
• DestroyMethodName: 빈의 생명주기가 끝나서 제거하기 직전에 호출되는 메서드 명
• Constructor arguments, Properties: 의존관계 주입에서 사용한다. (자바 설정 처럼 팩토리 역할
  의 빈을 사용하면 없음)

사실 BeanDefinition의 내부를 알 필요는 딱히 없지만, 스프링 프레임워크 코드나 스프링 관련 오픈소스 라이브러리를 볼 때 종종 BeanDefiniton를 직접 구현하는 경우가 있다. 그 때 해당 코드가 어떤 코드인지 이해를 돕기위해서 간단하게 설명해보았다.