IoC, DI 그리고 컨테이너

IoC(Inversion of Control)

프로그램의 제어의 흐름을 직접 하는 것이 아니라 외부에서 관리하는 경우 제어의 역전이라고 한다.
여기서 프레임워크와 라이브러리의 차이도 알 수 있는데 만약 내가 작성한 코드가 직접 제어를 담당한다면 라이브러리이고 그렇지 않다면 프레임워크라고 할 수 있다.

DI(Dependency Injection)

애플리케이션 실행 시점에 외부에서 실제 구현 객체를 생성한고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존 관계가 연결되는 것을 의존관계 주입이라고 한다.
객체 인스턴스를 생성하고 그 참조값을 전달해서 연결되는데 의존관계 주입을 사용함으로써 클라이언트 코드를 변경하지 않고 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
"정적인 클래스 의존관계"를 변경하지 않고 "동적인 객체 인스턴스 의존관계"(=실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계)를 쉽게 변경할 수 있다. 

IoC 컨테이너, DI 컨테이너

위의 AppConfig와 같이 객체를 생성하고 관리하면서 의존관계를 연결해주는 것을 IoC 컨테이너, DI 컨테이너라고 한다. 어셈블러 또는 오브젝트 팩토리라고 불리기도 한다.

따라서 스프링 컨테이너를 적용한 방식은 다음과 같다. 먼저 AppConfig 클래스에서 어노테이션들을 설정해줌으로써 컨테이너로 등록해준다. @Configuration이라고 붙은 클래스를 ApplicationContext에서 참조해서 사용할 수 있고 @Bean 어노테이션이 붙은 매서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다. 이 매서드명으로 getBean 매서드를 활용해 스프링 빈을 찾아 참조할 수 있다. 

등록한 컨테이너를 사용하는 방식은 다음과 같다. ApplicationContext를 스프링 컨테이너라고 한다. 컨테이너에 등록된 매서드명을 getBean 매서드를 활용해 찾고 스프링 빈을 참조할 수 있다. getBean(빈 이름, 타입)으로 조회 가능하며, getBean(타입) 으로도 조회 가능하다. 여기서 인터페이스 대신 구체 타입으로도  조회 가능하다. 즉, MemberService 뿐만 아니라 MemberServiceImpl로도 조회 가능하다는 의미이지만 권고하지는 않는다. -> 역할과 구현을 분리하는 것과 일맥 상

만약 빈이 존재하지 않는다면 'No bean named "이름" available이라는 문구를 보여준다.

존재하지 않는 빈을 조회하려 할 때 오류를 띄우는 것이 아니라 테스트에서 예외를 터지는 것을 확인하자면 다음과 같이 코드를 작성하면 된다.