1.16 BeanFactory by sh

1.16. The BeanFactory

BeanFactoryAPI는 기능적으로 스프링의 IoC를 위한 기본적인 기반을 제공합니다. 그것의 특정 계약은 스프링의 다른 부분과 관련된 third-party 프레임 워크와의 통합에 주로 사용되며, DefaultListableBeanFactory구현은 상위 수준의 GenericApplicationContext컨테이너 내의 주요 델리게이트입니다.

• DefaultListableBeanFactory : BeanFactory 구현 클래스. 거의 대부분의 스프링 컨테이너는 이 클래스를 이용해서 빈을 등록하고 관리한다. @Autowired로 주입받아서 이용할 수 있음. 빈을 조회할 수 있는 다양한 메소드 존재.

BeanFactory및 관련된 인터페이스(예: BeanFactoryAware, InitializingBean, DisposableBean)는 다른 프레임 워크 구성 요소의 중요한 통합 지점입니다. 어노테이션이나 리플렉션을 요구하지 않기 때문에 컨테이너와 컴포넌트 간의 효율적인 상호작용이 가능합니다. 응용 프로그램 수준의 빈은 동일한 콜백 인터페이스를 사용할 수 있지만 일반적으로 어노테이션 또는 프로그래밍 방식 구성을 통해 선언적 의존성 주입을 선호합니다.

핵심 BeanFactoryAPI 레벨과 그것의 DefaultListableBeanFactory구현은 사용되는 구성 포맷이나 컴포넌트 어노테이션에 대해 가정하지 않습니다. 이러한 모든 맛은 확장(예: XmlBeanDefinitionReader및 AutowiredAnnotationBeanPostProcessor)을 통해 들어오고 공유된 BeanDefinition객체를 핵심 메타 데이터 표현으로 동작하게 합니다. 이것은 스프링의 컨테이너를 매우 유연하고 확장성 있게 만드는 핵심 요소입니다.

즉, BeanFactory, DefaultListableBeanFactory 만으로는 어노테이션 사용 등 확장된 기능 제공 불가능.

1.16.1. BeanFactory or ApplicationContext?

이 섹션에서는 BeanFactory와 ApplicationContext컨테이너 레벨의 차이와 부트스트랩에 대한 영향에 대해 설명합니다.

GenericApplicationContext와 하위 클래스인 AnnotationConfigApplicationContext를 커스텀 부트스트래핑의 일반적인 구현으로 사용하지 않는 한, ApplicationContext를 사용해야합니다. 이것은 구성 파일의 로딩, 클래스 패스 스캔 실행, 빈 정의와 어노테이팅 된 클래스를 프로그래밍 방식으로 등록, 기능적인 빈 정의를 등록하는(5.0으로) 등 모든 공통 목적을 위한 스프링의 핵심 컨테이너에 대한 주요 진입 점입니다.

ApplicationContext는 BeanFactory의 모든 기능을 포함하고 있기 때문에, BeanFactory에 비해 일반적으로 권장됩니다. 단, 빈 처리에 대한 완전한 제어가 필요한 시나리오는 예외입니다. ApplicationContext(예: GenericApplicationContext구현) 내에서 일반 DefaultListableBeanFactory는 특수 빈에 대해 분가지론하는 반면, 몇 가지 종류의 빈이 규칙에 따라(즉, 빈 이름 또는 빈 유형, 특히 후 처리기에 의해) 감지됩니다.

어노테이션 처리 및 AOP 프록 싱과 같은 확장된 컨테이너 기능의 경우, BeanPostProcessor확장 점이 필수적입니다. 일반 DefaultListableBeanFactory만 사용하는 경우, 이러한 후 처리기는 기본적으로 검색되고 활성화되지 않습니다. 빈 구성에 실제로 아무 것도 없기 때문에 이 상황은 혼란스러울 수 있습니다. 오히려, 이러한 시나리오에서는 추가적인 설정을 통해 컨테이너를 완전히 부트스트랩해야 합니다.

다음 표는 BeanFactory및 ApplicationContext인터페이스 인터페이스 및 구현에서 제공되는 기능들을 나열합니다.

Table 9. 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 internalization)	No	Yes
Built-in ApplicationEvent publication mechanism	No	Yes

빈 post-processor를 DefaultListableBeanFactory에 명시적으로 등록하려면 다음 예제와 같이 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를 일반 DefaultListableBeanFactory에 적용하려면 다음 예제와 같이 postProcessBeanFactorymethod메소드를 호출 해야합니다:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));

// bring in some property values from a Properties file
PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
cfg.setLocation(new FileSystemResource("jdbc.properties"));

// now actually do the replacement
cfg.postProcessBeanFactory(factory);

두 경우 모두 명백한 등록 단계가 불편하기 때문에, 스프링을 지원하는 응용프로그램의 일반 DefaultListableBeanFactory보다 다양한 ApplicationContext변형이 선호됩니다. 특히 일반적인 앤터프라이즈 설치의 확장 컨테이너 기능을 위해 BeanFactoryPostProcessor및 BeanPostProcessor인스턴스를 사용하는 경우 더욱 그렇습니다.

AnnotationConfigApplicationContext는 모든 공통 어노테이션 post-processor가 등록되어 있으며, @EnableTransactionManagement와 같은 구성 어노테이션을 통해 커버 아래에 추가적인 프로세서를 가져올 수 있습니다. 스프링의 어노테이션 기반 구성 모델의 추상화 단계에서, 빈 post-processor의 개념은 단순한 내부 컨테이너 세부 사항이 됩니다.