스프링 핵심 원리 - 기본편 - (IOC, DI, 컨테이너)

제어의 역전

내가 코드를 호출하는 것이 아니라 프레임워크가 코드를 호출하는 것

프레임워크 vs 라이브러리
프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다 junit
반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.

의존관계 주입 DI

정적인 클래스는 클래스 다이어그램 생각하면 됨

동적 의존관계는 의존관계에서 어떤 것이 들어올지는 실행시켜봐야 안다.

즉 클래스 다이어그램이 변겨오디지 않고 동적인 객체 인스턴스만 변경할 수 있다.

IOC 컨테이너, DI 컨테이너

AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IOC 또는 DI 컨테이너라고 한다.

스프링 컨테이너

ApplicationContext를 스프링 컨테이너라 한다.
기존에는 개발자가 AppConfig를 사용해서 직접 객체를 생성하고 DI했지만 이제부터는 스프링 컨테이너를 사용해서 사용한다.
스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용한다. 여기서 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 등록된 객체를 스프링 빈이라한다.
스프링빈의 이름은 메서드명으로 이름을 한다.
이전에는 개발자가 AppConfig를 사용해서 직접 조회했지만, 스프링 컨테이너를 통해 스프링 빈을 찾아야한다.
applicationContext.getBean을 통해 스프링빈을 가져온다.

스프링 컨테이너를 사용하면 어떤 장점이 있을까?