IoC, DI, 컨테이너

제어의 역전 IoC(Inversion of Control)

-(기존) 구현체가 프로그램의 제어 흐름을 스스로 조종 -> AppConfig가 모든 제어 흐름의 권한을 가짐

-프로그램의 제어 흐름을 직접 제어가 아닌 외부에서 관리하는것을 제어의 역전이라 함

-작성한 코드를 제어하고 대신 실행 -> 프레임 워크(JUnit)

-개발자가 작성한 코드가 직접 제어 흐름을 담당 -> 라이브러리

 

의존관계 주입 DI

 

-실행 시점에 외부에서 실제 구현체를 생성하고 클라이언트에 전달해서 서버와의 실제 의존관계가 연결되는것

-정적인 클래스 의존관계: 애플리케이션 실행하지 않고 분석가능(클래스 다이어그램)

-정적인 클래스 만으로는 실제 어느 구현체를 사용했는지 알수없음

-동적인 객체 인스턴스 의존관계: 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결

-정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스터스 의존관계를 쉽게 변경 가능(OCP)

 

IoC 컨테이너, DI 컨테이너

-AppConfig 같이 객체를 생성하고 관리하면서 의존관계를 연결해주는것을 IoC 컨테이너 또는 DI 컨테이너라고 함

 

스프링 컨테이너

-ApplicationContext를 스프링 컨테이너라 함

-AppConfig 대신 스프링 컨테이너를 통해서 DI를 해야함

-@Configuration이 붙은 AppConfig를 설정 정보로 사용함

-@Bean이 적힌 메서드를 모두 호출해서 반환된 객체(스프링 빈)를 스피링 컨테이너에 등록

-스프링 컨테이너에서 스프링 빈을 찾아 사용

-더 복잡해짐? 스프링 컨테이너가 관리함으로써 사용할수 있는 기능이 매우 많아짐