[스프링] IoC컨테이너: 빈 팩토리와 애플리케이션 컨텍스트

애플리케이션 컨텍스트 (Application Context)

• 스프링 애플리케이션에서는 오브젝트의 생성과 관계설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신 독립된 컨테이너가 담당
• 제어의 역전 (Inversion of Control): 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고있음을 의미
• 스프링 컨테이너를 IoC 컨테이너라고도 함
• 애플리케이션 컨텍스트는 그 자체로 IoC와 DI를 위한 빈팩토리이면서 그 이상의 기능을 가졌음

ApplicationContext와 BeanFactory의 관계

• 둘 다 스프링에서 제공하는 인터페이스.
• ApplicationContext는 BeanFactory 인터페이스를 상속받음

public interface ApplicationContext extends ListableBeanFactory, HierarchicalBeanFactory, ... {
}

BeanDefinition: 스프링 설정 메타정보 추상화

• 스프링의 설정정보를 XML로만 생각하는 것은 스프링에 대한 대표적인 오해
• 스프링의 설정 메타정보는 BeanDefinition 인터페이스로 표현되는 순수한 추상 정보
• 스프링의 메타정보는 특정한 파일 포맷이나 형식에 제한되거나 종속되지 않음
  • 대표적으로 XML파일, 자바 소스코드 애노테이션, 자바 클래스 3가지 방식 사용 가능
  • 요즘은 YAML 많이 사용
• 어떤 형식이든 BeanDefinitionReader를 통해 BeanDefinition 오브젝트로 변환하여 스프링 설정 메타정보 작성 가능
  • ex) XmlBeanDefinitionReader, PropertiesBeanDefinitionReader, …

 

 

 

하나의 클래스, 여러개의 빈 케이스

IoC 컨테이너가 관리하는 빈은 오브젝트 단위임. 클래스 단위가 아님

경우에 따라서 하나의 클래스를 여러개의 빈으로 등록하기도 함

이유: 빈마다 다른 설정을 지정해두고 사용하기 위함

예시: 사용할 DB가 여러개일 때 같은 SimpleDriverDataSource 클래스로 된 빈을 여러개 등록하고 각각 다른 DB 설정을 지정해서 사용 가능

(기술 서비스 빈이 아니라면 대부분 클래스당 하나 이상의 빈을 등록하는 경우는 없다고 함)

IoC 컨테이너 종류

종류	특징
StaticApplicationContext	- 코드를 통해 빈 메타정보를 등록하기 위해 사용 - 실제로 사용되지는 않음 (실전에서 사용하면 안됨) - 학습 테스트 검증 시 유용
GenericApplicationContext	- 가장 일반적인 애플리케이션 컨텍스트의 구현 클래스 - 실전에서 사용될 수 있는 모든 기능을 갖추고 있음 - 컨테이너의 주요 기능을 DI를 통해 확장할 수 있도록 설계되어있음 - 외부의 리소스에 있는 빈 설정 메타정보를 리더를 통해 읽어들여서 메타정보로 전환해서 사용 - 코드에서 직접 만들고 초기화하진 않지만 실제로는 자주 사용됨 (ex JUnit 테스트 실행 시 애플리케이션 컨텍스트를 자동으로 만들어줌) - Spring Boot는 (MVC) GenericApplicationContext를 상속받은 GenericWebApplicationContext를 사용 - Webflux는 GenericReactiveWebApplicationContext
GenericXmlApplicationContext	- XmlBeanDefinitionReader와 GenericApplicationContext가 결합된 방식 - 코드에서 GenericApplicationContext를 사용하는 경우에 적합
WebApplicationContext	- 스프링 애플리케이션에서 가장 많이 사용되는 방식 - 스프링 애플리케이션은 대부분 서블릿 기반의 독립 웹 애플리케이션(WAR)로 만들어지기 때문

 

SpringBoot 실제 코드에서 컨테이너 종류 탐색해보기

ApplicationContextFactory에서 webApplicationType에 맞게 컨텍스트 팩토리 오브젝트 생성

현재 SERVLET 타입이기 때문에 ServletWebServerApplicationContextFactory에서 컨텍스트 생성

 

상속 클래스를 따라가다보면 GenericApplicationContext를 사용 중임을 확인할 수 있음

 

GenericApplicationContext는 BeanDefinitionRegistry 인터페이스의 구현체

 왜 책에선 WebApplicationContext만 언급했을까?

토비의 스프링이 다루던 시점(Spring 3.x ~ 4.x)은:

• 대부분의 웹 환경에서 XmlWebApplicationContext, AnnotationConfigWebApplicationContext 같은 클래스들을 직접 사용했음
• 당시엔 유연성과 확장성을 위해 GenericWebApplicationContext는 그다지 실무에서 많이 사용되지 않았음

Spring Boot는 이후 버전부터 이 모든 걸 추상화하고 자동 설정하기 시작하면서,

• 더 이상 명시적인 WebApplicationContext 구현을 선택할 필요 없이
• GenericWebApplicationContext를 기반으로 다양한 설정을 "자동"으로 처리하게 되었음

 

 

일반적인 애플리케이션의 기동 방식

main() 메소드처럼 어디에선가 특정 빈 오브젝트의 메소드를 호출함으로써 애플리케이션을 동작시킴

웹 애플리케이션의 동작 방식 - 서블릿 컨테이너

웹에서는 main() 메소드를 호출할 방법이 없음

그래서 웹 환경에서는 main() 대신 서블릿 컨테이너가 브라우저로부터 오는 HTTP 요청을 받아서 해당 요청에 매핑되어 있는 서블릿을 실행해주는 방식으로 동작함

과정

main() 메소드 역할을 하는 서블릿을 만들어두기 → 미리 애플리케이션 컨텍스트를 생성 → 요청이 서블릿으로 들어올 때마다 getBean()으로 필요한 빈을 가져와 정해진 메소드를 실행

 

 

IoC 컨테이너 계층 구조

 

모든 애플리케이션 컨텍스트는 부모 애플리케이션 컨텍스트를 가질 수 있음

각자 독립적으로 자신이 관리하는 빈을 갖고있긴 하지만 DI를 위해 빈을 찾을 때는 부모 애플리케이션 컨텍스트의 빈까지 모두 검색

자식 컨텍스트에게는 빈 검색 요청하지 않음

같은 맥락으로 동일 레벨 형제 컨텍스트의 빈도 검색 불가

기본적으로 스프링 웹 애플리케이션은 부모/자식 관계를 가진 두 개의 애플리케이션 컨텍스트로 구성된 계층구조로 만들어짐

 

usecase

• 기존 설정을 수정하지 않고 사용하지만 일부 빈 구성을 바꾸고 싶은 경우
• 여러 애플리케이션 컨텍스트가 공유하는 설정을 만드는 경우

주의점

• 어느 것이 루트/자식 컨텍스트인지 분명하게 알아야 함
• AOP처럼 컨텍스트 안의 많은 빈에 일괄적으로 적용되는 기능은 대부분 해당 컨텍스트로 제한됨

 

 

웹 애플리케이션의 IoC 컨테이너 구성

자바 서버에는 하나 이상의 웹 모듈 배치 가능한 특성을 이용해 하나의 웹 애플리케이션은 여러 서블릿을 가질 수 있음

많은 웹 요청을 한 번에 받을 수 있는 대표 서블릿을 등록해두고, 각 요청의 기능을 담당하는 핸들러 클래스를 호출하는 방식

프론트 컨트롤러 패턴: 몇 개의 서블릿이 중앙집중식으로 모든 요청을 다 받아서 처리하는 방식

계층구조 방식의 이유: 전체 애플리케이션에서 웹 기술에 의존적인 부분과 그렇지 않은 부분을 구분하기 위해

 

일반적으로는 프론트 컨트롤러 역할의 서블릿은 하나만 만들어서 사용

 

 

웹 애플리케이션 컨텍스트 구성 방법

서블릿 컨텍스트와 루트 애플리케이션 컨텍스트 계층구조	- 가장 많이 사용하는 기본적인 구성 방법 - 웹 관련 빈들은 서블릿 컨텍스트에 두고 나머지는 루트 애플리케이션 컨텍스트에 등록
루트 애플리케이션 컨텍스트 단일 구조	- 스프링 웹 기술 사용하지 않고 서드파티 웹 프레임워크 등으로 프레젠테이션 계층을 만든다면 서블릿이 필요 없음 - 이 때는 루트 컨텍스트만 사용
서블릿 컨텍스트 단일 구조	- 스프링 웹 기술 사용하면서 스프링 외의 프레임워크나 서비스 엔진에서 스프링 빈 이용하지 않을 경우 루트 컨텍스트 생략 가능