애플리케이션 컨텍스트
스프링에서는 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트를 빈(bean)이라하고 빈의 생성과 관계설정 같은 제어를 담당하는 IoC 오브젝트를 빈 팩토리(bean factory)라고 부른다.
그리고 스프링에서는 빈 팩토리를 확장한 애플리케이션 컨텍스트(application context)를 주로 사용한다. 애플리케이션 컨텍스트는 IoC 방식을 따라 만들어진 일종의 빈 팩토리라고 생각하면 된다.
1
2
3
4
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory,
HierarchicalBeanFactory, MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
....
}
- MessageSource: 국제화 기능
- EnvironmentCapable: 로컬, 개발, 운영등을 구분해서 처리
- ApplicationEventPublisher: 이벤트를 발행하고 구독하는 모델을 편리하게 지원
- ResourceLoader: 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회
- BeanFactory: 스프링 컨테이너의 최상위 인터페이스로 스프링 빈을 관리하고 조회하는 역할
애플리케이션 컨텍스트는 별도의 정보를 참고해서 빈의 생성, 관계설정 등의 제어 작업을 총괄한다.
기존 MemberFactory 코드에는 설정정보, 예를 들어 어떤 클래스의 오브젝트를 생성하고 어디에서 사용하도록 연결해줄 것인가 등에 관한 정보가 평범한 자바 코드로 만들어져 있다. 애플리케이션 컨텍스트는 이런 정보를 담고 있진 않다. 대신 별도로 설정정보를 담고 있는 무엇인가를 가져와 이를 활용하는 범용적인 IoC엔진 같은 것이라고 볼 수 있다.
애플리케이션 컨텍스트의 동장방식
기존에 오브젝트 팩토리를 이용했던 방식과 스프링의 애플리케이션 컨텍스트를 사용한 방식을 비교해보자.
오브젝트 팩토리에 대응되는 것이 스프링의 애플리케이션 컨텍스트다. 스프링에서는 이 애플리케이션 컨텍스트를 IoC 컨테이너라 하기도 하고, 간단히 스프링 컨테이너라고 부르기도 한다. 또는 빈 팩토리라고 부를 수도 있다.
우리가 이전 포스팅에서 만든 MemberFactory는 MemberRepository 오브젝트를 생성하고 이를 활용하는 오브젝트와 관계를 맺어주는 제한적인 역할을 한다. 반면에 애플리케이션 컨텍스트는 애플리케이션에서 IoC를 적용해서 관리할 모든 오브젝트에 대한 생성과 관계설정을 담당한다.
또한 애플리케이션 컨텍스트는 MemberFactory와 달리 직접 오브젝트를 생성하고 관계를 맺어주는 코드가 없고, 그런 생성정보와 연관관계 정보를 별도의 설정정보를 통해 얻는다.
@Configuration이 붙은 MemberFactory는 이 애플리케이션 컨텍스트가 활용하는 IoC 설정정보다.
내부적으로는 애플리케이션 컨텍스트가 MemberFactory의 memberRepository() 메소드를 호출해서 오브젝트를 가져온 것을 클라이언트가 getBean()으로 요청할 때 전달해준다. 
애플리케이션 컨텍스트를 사용할 경우 장점
- 클라이언트는 구체적인 팩토리 클래스를 알 필요가 없다
- 애플리케이션 컨텍스트는 종합 IoC 서비스를 제공해준다
- 애플리케이션 컨텍스트는 빈을 검색하는 다양한 방법을 제공한다
Comments powered by Disqus.