DI Container = ApplicationContext의 또 다른 이름..

다시 간단 정리하면 스프링이라는 프레임워크는 개발자의 코드를 수동적으로 만든다.

1. 개발자의 코드는 능동적으로 스스로 실행되지 않는다. (객체화되지 않는다.)

--> 스프링 프레임워크가 실행시켜줘야 실행된다.

2. 개발자의 코드는 오브젝트와의 의존관계를 스스로 결정하고 맺지 않는다. 

--> 스프링 프레임워크가 런타임시에 오브젝트간 의존관계를 맺어준다.

--> 스프링이 이런 역할을 해주기 때문에. Bean Factory/ ApplicationContext/ IoC 컨테이너/ SingltoneRegistry 등의 많은 이름(?)으로 불리우는 이 것이 DI 컨테이너라는 또 다른 이름으로 불리우는 이유다.

스프링이 DI Container 로서, 

Dependency Injection(의존성 주입)을 잘 할 수 있게끔 하려면..

개발자는 클래스를 설계하고 코딩시에 의존 관계를 Class가 아닌 Interface와 맺도록 한다.
(능동적으로 특정 클래스와의 관계를 직접 맺지 마라..)

그래야 스프링의 DI Container가 할 일이 있지 않겠나? 

개발자가 클래스가 아니라 인터페이스를 사용하도록 코딩해두면, 스프링의 DI Container가 해당 인터페이스를 구현한 클래스의 오브젝트를 생성/관리 하고 있다가 선택하여 적당한 run time 시기에 그 Object의 reference를 주입해준다. 

이것이 Dependency Injection이다.

예제)

Class B Implements IF {..}

Class A {

private B b;

public A(B b) { 

this.b = b; 

}

} // 개발자가 직접 특정 클래스와 의존관계를 맺음

Class C {

private IF f;

public A(IF f) { 

this.f = f; 

}

} //스프링이 IF를 구현한 클래스중에 선택해서 넣어줌

주의) 

Class B와 Class C는 둘 다 스프링에 의해 관리되는 Bean 으로 등록되어야 한다.

다시 말해, DI를 받고 싶으면, DI로 전달되는 클래스 뿐만 아니라 DI를 받는 클래스도 빈이 되어야 한다.