Bean
스프링이 제어권을 가져서 직접 생성하고 의존관계를 부여하는 객체를 빈이라고 부른다.
BeanFactory vs ApplicationContext
-
BeanFactory-
빈을 생성하고 의존관계를 설정하는 기능을 담당하는 가장 기본적인 IoC 컨테이너이자 클래스를 말한다. 스프링 빈 컨테이너에 접근하기 위한 최상위 인터페이스이다.
-
스프링 빈을 관리하고 조회하는 역할을 담당한다.
-
getBean()을 제공한다. -
Lazy-loading 방식을 사용한다
빈을 사용할 때 빈을 로딩한다. ( 필요할 때만 로딩하기 때문에, 가벼운 경량 컨테이너이다. )
-
-
ApplicationContext-
BeanFactory를 확장하고 있어 BeanFactory의 확장된 버전이라고 생각해도 좋다.
-
Eager-loading 방식을 사용한다
런타임 실행시 모든 빈을 미리 로딩시킨다.
-
MessageSource를 이용한 국제화 기능 -
EnvironmentCapable환경 변수를 이용한 로컬, 개발, 운영 구분 -
ApplicationEventPublisher애플리케이션 이벤트를 이용하여, 이벤트를 발행하고 구독하는 모델을 편리하게 지원 -
ResourceLoader를 이용하여 편리하게 파일, 클래스패스 등의 리소스를 조회
-
BeanFactory라고 말을 할때는 빈을 생성하고 관계를 설정하는 IoC의 기본 기능에 초점을 맞춘 것이다.
ApplicationContext라고 말을 할때는 별도의 정보를 참고해서 빈의 생성, 관계 설정 등의 제어의 총괄에 초점을 맞춘 것이다.
스프링 공식문서에 의하면 특별한 경우가 아니라면 BeanFactory의 모든 기능을 포함하고 추가 기능을 제공하는 ApplicationContext를 사용하기를 권장하고 있다고 한다.
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
...
}위 코드는 ApplicationContext의 일부분이다. BeanFactory를 확장하고 있는 ListableBeanFactory와 HierachicalBeanFactory를 다시 ApplicationContext가 확장하는 구조를 가지고 있음을 확인할 수 있다. 이 외에 위에서 언급했던 여러 기능들 또한 확장받고 있다.
ApplicationContext 사용을 권장하는 이유?
JPA에서는 Eager Loading을 지양하고 Lazy Loading을 사용하라고 배웠었다. 그렇다면 스프링 공식문서에서는 어째서 Bean의 Eager Loading을 사용하는 ApplicationContext 사용을 권장할까?
문제가 있는 Bean 객체가 있을 때, Lazy Loading을 사용하게 되면 해당 Bean이 사용되는 시점이 되기 전까지 해당 오류의 유무를 파악하기가 어렵다. 때문에 Eager Loading을 사용하여, 객체의 초기화 시점에 오류를 잡아내기 위함이라고 생각한다.
그렇다면 ApplicationContext는 항상 Eager Loading만 사용이 가능할까? 그리고 Lazy Loading은 항상 좋지 않을까?
그렇지 않다. 근본적으로 BeanFactory를 확장하고 있기 때문에, BeanFactory에서 제공하는 Lazy Loading도 사용이 가능하다. 그리고 Lazy Loading을 사용해서 초기화 시점에 오류를 잡지 못한다고 해서, 나쁜것만 있는 것은 아니다. 스프링 통합 테스트를 진행할 경우, Eager Loading을 사용하게 되면 모든 빈이 한번에 컨테이너에 올라가게 되므로 많은 실행 시간이 소요되게 된다. 프로젝트를 진행하다보면 수 없이 테스트를 진행해야하는데, 전역적으로 Eager Loading으로 설정이 되어있으면 이러한 문제가 생기는 것이다. 필요한 부분에 별도로 Lazy Loading을 설정함으로써, 이러한 부분을 개선할 수 있도록 스프링 부트는 기능을 제공하고 있다.
