스프링의 BeanFactory와 ApplicationContext의 차이

해당 글에서 ApplicationContext는 DI 컨테이너라고 했다.
그렇다면 BeanFactory는 무엇을까?

스프링의 컨테이너의 최상위 인터페이스

---

• 보통은 ApplicationContext에서 빈을 조회하는 코드를 작성할 것이다. 그게 가능한 이유는 BeanFactory를 상속 받았기 때문이다.
  즉, getBean()과 같은 것은 BeanFactory가 제공해주는 기능인 것이다.
• 결과 적으로 빈을 조회하고 관리하는 역할이 BeanFactory인 것이다.

그럼 ApplicationContext는 왜 사용하지?

---

그렇다. 그냥 BeanFactory를 사용하면 되지 왜 ApplicationContext를 사용할까? 복잡하게.. 이유는 부가 기능이 필요하기 때문이다.

ApplicationContext의 구조를 보면 이렇다.

실제 소스를 까보면 알 수 있다.

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
        MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
....
}

아주 많은 인터페이스들이 있는데 ListableBeanFactory은 BeanFactory를 상속 받았기 때문에 BeanFactory라고 생각하면 된다.
하지만 다른 인터페이스들을 보면(지금 정확히 알 필요는 없다.), 메시지 국제화, 환경 변수 등등 부가 기능을 제공하는 인터페이스들이 많다.
개발을 하는데 빈을 조회하고 관리만 하는 것으로는 부족하기 때문에 이러한 여러 부가 기능들을 사용하기 위해 BeanFactory가 아닌 ApplicationContext를 사용하는 것이다.

정리

---

• ApplicatitonContext는 BeanFactory를 상속 받는다.
• BeanFactory는 빈의 조회, 관리의 역할을 한다.
• ApplicationContext는 빈 관리 기능 + 부가 기능을 제공한다.
• BeanFactory는 거의 사용할 일이 없고, ApplicationContext를 사용한다.
• 결국 BeanFactory와 ApplicationContext모두 스프링의 DI 컨테이너이다.