스프링 DI

 

DI

런타임 시점의 의존관계를 결정하고 만들려면 제 3의 존재가 필요하다.

 

흔히 스프링을 사용하지 않으면 Factory 가 그 역할을 담당한다. Factory 는 두 오브젝트 사이의 런타임 의존관계를 설정해주는 의존관계 주입 작업을 주도하는 존재이며, 동시에 IoC 방식으로 오브젝트의 생성과 초기화, 제공 등의 작업을 수행하는 컨테이너다.

 

따라서 의존관계 주입을 담당하는 컨테이너라고 볼 수 있고, 줄여서 DI 컨테이너라고 불러도 된다. 

 

의존관계 검색과 주입

 

스프링이 제공하는 IoC 방법에는 의존관계 주입만 있는 것이 아니다. 코드에서는 구체적인 클래스에 의존하지 않고 런타임 시에 의존관계를 결정한다는 점에서 의존관계 주입과 비슷하지만, 의존관계를 맺는 방법이 외부로부터의 주입이 아니라 스스로 검색을 이용하기 때문에 의존관계 검색 이라고 불리는 것도 있다.

 

의존관계 검색은 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는다. 물론 자신이 어떤 클래스의 오브젝트를 이용할지 결정하지는 않는다. 그러면 IoC 라고 할 수는 없다.

 

하지만 코드상으로 보면 의존관계 주입쪽이 훨씬 깔끔하다. ( 왜냐면 검색하는 애플리케이션 컨텍스트를 직접 사용해서 ) 

 

DI 기술의 장점

1. 객체지향 설계와 프로그래밍의 원칙을 따랐을 때 얻을 수 있는 장점이 그대로 녹아있다.

2. 인터페이스를 통해 결합도가 낮은 코드를 만들므로, 다른 책임을 가진 사용 의존관계에 있는 대상이 바뀌거나 변경되더라도 자신은 영향을 받지 않는다.

 

 

추가

 

가끔씩 인터페이스를 사용하지 않는 엄밀히 말하자면 온전한 DI를 사용하지 않은 객체가 있을 수 있다. 그러나 스프링의 DI는 넓게 보면 객체의 생성과 관계설정에 대한 제어권한을 오브젝트에서 제거하고 외부로 위임했다는 IoC 라는 개념을 포괄하기 때문에 DI 에 기본을 따르고 있다고 볼 수 있다.

 

그렇다면 이런 객체 ( 인터페이스를 만들지 않은 하지만 DI 가 필요한 객체 ) 를 DI 구조로 만들어야 할 이유는 무엇인가?

 

첫째는 스프링 컨테이너의 싱글톤 레지스트리에서 관리되는 싱글톤 빈이 되기 때문이다.

- 보통 이런 객체는 그 자체로 상태정보를 가지고 있지 않아야 한다.

 

둘째는 DI 를 통해 다른 빈에 의존하고 있기 때문이다. 이 두번째 이유가 중요하다. 서로 의존관계가 있기 때문에 주입의 중간 빈역할을 해준다.