# 스프링 컨테이너

스프링 컨테이너

의존관계 주입을 대신 객체를 생성하고 관리하면서 의존관계를 연결해주는 것

스프링 프레임워크도 객체를 생성하고 관리하고 책임지고 의존성을 관리해주는 컨테이너가 있는데,
그것이 바로 스프링 컨테이너( = IoC 컨테이너, DI 컨테이너, 어샘블러, 오브젝트 팩토리...등)

인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자가 아닌 컨테이너가 대신 해준다
객체관리 주체가 프레임워크(Container)가 되기 때문에 개발자는 로직에 집중할 수 있는 장점이 있다

• IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다
• 개발자들이 직접 POJO를 생성할 수 있지만 컨테이너에게 맡긴다
• 개발자는 비즈니스 로직에 집중할 수 있다
• 객체 생성 코드가 없으므로 TDD가 용이

@Configuration : 구성정보를 담당하는것을 설정할때 @Configuration 을 붙여준다

@Bean : 각 메서드에 @Bean을 붙이면 스프링 컨테이너에 자동으로 등록
(개발자가 ...Config라는 파일을 만들어 수동으로 @Bean 이라는 애노테이션을 붙여줘야 한다)

ApplicationContext (스프링 컨테이너) :

스프링 컨테이너는 @Configuration이 붙은 클래스를 설정정보로 사용

• @Bean이 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록
• 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다
• 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다
• 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 스프링 빈을 등록

예)new AnnotationConfigApplicationContext(스프링.class) 이라 하면 스프링에 있는 @Bean의 메서드를 등록

스프링 빈 조회에서 상속관계가 있을 시에, 부모타입으로 조회하면, 자식 타입도 함께 조회

그래서 모든 자바 객체의 최고 부모인 object타입으로 조회하면 모든 스프링 빈을 조회

예) getBean(스프링.class)

BeanFactory vs ApplicationContext

BeanFactory

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

스프링 빈을 관리하고 조회하는 역할을 담당

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공

빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주지만 이외에 부가기능을 제공

• MessageSource : 메세지소스를 활용한 국제화 기능 (한국어,영어 등)
• EnvironmentCapable : 환경변수 (로컬,개발,운영등을 구분해서 처리)
• ApplicationEventPublisher : 이벤트를 발행하고 구독하는 모델을 편리하게 지원
• ResourceLoader : 파일, 클래스패스, 외부 등 리소스를 편리하게 조회

ApplicationContext는 BeanFactory의 기능을 상속

ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공

BeanFactory를 직접 사용하는 일은 거의 없으며, 부가기능이 포함된 ApplicationContext를 사용

BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다

@Configuration이 붙어 있는 클래스에서 @Bean이 붙은 클래스들을 모두 BeanFactory에 자동으로 올라가게 되고 그 값을 스프링 컨테이너가 참조하여 실행한다 여기서 제어의 역전이 일어나 개발자가 직접 메서드를 쓰고 클래스의 의존관게를 연결해 주는것이 아닌 스프링 컨테이너가 제어권을 가져가 실행