The BeanFactory API

BeanFactory API는 Spring의 IoC 기능의 기본 기반을 제공합니다. 해당 특정 인터페이스들은 주로 Spring의 다른 부분 및 관련 타사 프레임워크와의 통합에서 사용되며, DefaultListableBeanFactory 구현은 상위 수준의 GenericApplicationContext 컨테이너 내에서 key delegate 로 작동합니다.

BeanFactory와 관련된 인터페이스(BeanFactoryAware, InitializingBean, DisposableBean 등)는 다른 프레임워크 구성 요소와의 중요한 통합 지점을 제공합니다. 애노테이션이나 심지어 리플렉션도 요구하지 않으므로 컨테이너와 구성 요소 간의 매우 효율적인 상호작용이 가능합니다. 애플리케이션 레벨의 빈은 동일한 콜백 인터페이스를 사용할 수 있지만, 일반적으로 애노테이션이나 프로그래밍 방식의 구성 등을 통한 선언적 의존성 주입을 선호합니다.

핵심 BeanFactory API 레벨 및 DefaultListableBeanFactory 구현은 구성 형식이나 사용될 구성 요소 애노테이션에 대한 가정(예: XML, Java 기반 구성 메타데이터 또는 @Component, @Autowired)을 하지 않는다는 점에 유의해야 합니다. 이러한 모든 방식은 확장(예: XmlBeanDefinitionReader 및 AutowiredAnnotationBeanPostProcessor)을 통해 제공되며, 핵심 메타데이터 표현으로서 공유 BeanDefinition 객체에서 작동합니다. 이것이 Spring의 컨테이너를 매우 유연하고 확장 가능하게 만드는 본질입니다.

 

BeanFactory or ApplicationContext?

이 섹션은 BeanFactory와 ApplicationContext 컨테이너 레의 차이점과 부트스트래핑에 미치는 영향을 설명합니다.

특별한 이유가 없다면 ApplicationContext를 사용하는 것이 좋습니다. 일반적인 구현으로는 사용자 정의 부트스트래핑을 위한 GenericApplicationContext와 그 하위 클래스인 AnnotationConfigApplicationContext가 있습니다. 이들은 Spring의 핵심 컨테이너에 대한 주요 진입점으로, 다음과 같은 일반적인 목적에 사용됩니다: configuration files 로드, classpath scan 트리거, bean definitions 및 annotated classes의 프로그래밍 방식 등록, 그리고 (5.0부터) functional bean definitions 등록.

ApplicationContext는 BeanFactory의 모든 기능을 포함하기 때문에, 빈 처리를 완전히 제어해야 하는 시나리오를 제외하고는 일반적으로 단순한 BeanFactory보다 권장됩니다. ApplicationContext(예: GenericApplicationContext 구현) 내에서는 관례에 따라(예: 빈 이름이나 빈 타입, 특히 후처리기) 여러 종류의 빈이 감지되지만, 단순한 DefaultListableBeanFactory는 이러한 특별한 빈에 대해 무관심합니다.

애노테이션 처리나 AOP 프록시와 같은 많은 확장 컨테이너 기능에서는 BeanPostProcessor 확장 지점이 필수적입니다. 단순한 DefaultListableBeanFactory만 사용하는 경우, 이러한 후처리기가 기본적으로 감지되고 활성화되지 않습니다. 이 상황은 실제로 빈 구성에 문제가 없음에도 불구하고 혼란을 야기할 수 있습니다. 이 경우 컨테이너는 추가 설정을 통해 완전히 부트스트랩되어야 합니다.

다음 테이블은 BeanFactory와 ApplicationContext 인터페이스 및 구현에서 제공하는 기능을 나열합니다.

 

Table 1. Feature Matrix

Feature	BeanFactory	ApplicationContext
Bean instantiation/wiring	Yes	Yes
Integrated lifecycle management	No	Yes
Automatic BeanPostProcessor registration	No	Yes
Automatic BeanFactoryPostProcessor registration	No	Yes
Convenient MessageSource access (for internationalization)	No	Yes
Built-in ApplicationEvent publication mechanism	No	Yes

 

DefaultListableBeanFactory에 BeanPostProcessor를 명시적으로 등록하려면, 다음 예제와 같이 프로그래밍 방식으로 addBeanPostProcessor를 호출해야 합니다:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
// populate the factory with bean definitions

// now register any needed BeanPostProcessor instances
factory.addBeanPostProcessor(new AutowiredAnnotationBeanPostProcessor());
factory.addBeanPostProcessor(new MyBeanPostProcessor());

// now start using the factory

 

두 경우 모두 명시적인 등록 단계가 번거롭기 때문에, 특히 일반적인 엔터프라이즈 환경에서 확장된 컨테이너 기능을 위해 BeanFactoryPostProcessor와 BeanPostProcessor 인스턴스에 의존할 때, Spring 기반 애플리케이션에서는 단순한 DefaultListableBeanFactory 보다 다양한 ApplicationContext 변형을 선호합니다.

AnnotationConfigApplicationContext는 모든 일반적인 애노테이션 post-processor가 등록되어 있으며, @EnableTransactionManagement와 같은 구성 애노테이션을 통해 추가적인 post-processor를 내부적으로 가져올 수 있습니다. Spring의 애노테이션 기반 구성 모델 추상화 레벨에서는 BeanPostProcessor의 개념이 단순히 내부 컨테이너의 세부 사항이 됩니다.