일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- lambda
- 토비의스프링
- 빌드툴
- springboot
- exception
- Immutable
- IOC
- 클린코드
- beanfactory
- hibernate
- 링커
- FunctionalInterfaces
- 메이븐
- 컴퓨터시스템
- gradle
- 링킹
- java
- Spring
- AutoConfiguration
- String
- 토비의스프링3.1
- Kotlin for Java Developers
- 프록시
- springwebmvc
- 자바
- DispatcherServlet
- ORM
- DesignPattern
- JPA
- ApplicationContext
- Today
- Total
엔지니어로 가는 길
BeanFactory vs ApplicationContext 본문
ApplicationContext를 쓰지 말아야 할 특별한 이유가 있지 않는 한 ApplicationContext를 쓰는 게 좋다. (ApplicationContext는 interface이다. ApplicationContext의 구현체로는 GenericApplicationContext 또는 AnnotationConfigApplicationContext를 주로 사용한다.) 이들은 스프링의 컨테이너에 주요한 entry point를 제공한다. 예를 들면 이들을 통해서 설정 파일을 로드하거나 클래스 패스 스캔을 하거나 프로그래밍적으로 빈 정의와 어노테이션이 붙은 클래스를 정의하거나 함수적 빈 정의(spring 5.0부터 지원)를 등록하는 일을 할 수 있다.
ApplicationContext가 BeanFactory의 모든 기능을 포함하기 때문에 빈을 처리하는 데 있어 전반적인 컨트롤이 필요한 경우가 아니라면 BeanFactory를 쓰는 것보다 ApplicationContext를 쓰는 게 좋다. ApplicationContext에서는 (GenericApplicationContext와 같은 구현체에서는) 일부 빈이 convention으로 찾아진다. 다시 말해서, 별도의 설정을 하지 않아도 일부 빈은 빈의 이름이나 빈의 타입으로 찾아진다. 하지만 DefaultListableBeanFactory는 빈에 대해 아무것도 모른다.
어노테이션 처리, AOP 프록싱과 같은 확장된 컨테이너의 특징을 쓰기 위해서는 BeanPostProcessor의 확장 포인트가 필수적이다. 만약 DefaultListableBeanFactory만을 사용한다면 그러한 post-processors는 default로 찾아지거나 활성화되지 않는다.
아래의 표는 BeanFactory와 ApplicationContext의 특징을 나타낸 표이다.
원문:
https://docs.spring.io/spring-framework/docs/current/spring-framework-reference/core.html#beans-beanfactory
'프로그래밍 > Spring' 카테고리의 다른 글
스프링의 IoC 컨테이너: BeanFactory와 ApplicationContext (0) | 2020.04.17 |
---|---|
스프링 프레임워크란 (0) | 2020.04.14 |
DispatcherServlet이 요청을 처리하는 과정 (0) | 2020.03.10 |
spring web mvc에서 서블릿 설정하기 (0) | 2020.03.09 |
DispatcherServlet이 사용하는 '특별한 빈'은 어떻게 설정되는가 (0) | 2020.03.05 |