블로깅을 하다가
Spring Framework의 주요개념중 하나인 DI에 대해 설명이 잘된 글이 있어 포스팅한다.
Spriing에서 DI(=, AOP 개념만 정확히 이해한다면
스프링의 모든걸 알았다고 해도 과언이 아닌데
사실 이 개념들을 이해하기 쉽게 풀어쓴 글이나 서적은 별로 못본것 같다.
이 글은 DI가 어떤 개념인지, 이개념을 Framework에 도입하면 왜 유용한지를
알기쉽게 잘 설명하고 있다.
특히 컨테이너의 개념과 역할, 컴포넌트(Bean)과의 연관관계에 대한 설명이 훌륭하다.
일반적으로 어플리케이션은 컴포넌트들을 조합하여 이루어진다고 가정하자. 컴포넌트란 소프트웨어 모듈로서 더 이상의 수정이 없이도 사용할 수 있는 라이브러리를 뜻한다. 이 때, 어플리케이션을 구성하는 과정에서 각 컴포넌트들 사이의 결합은 서로가 서로를 호출하는 형태로 이루어진다.
이러한 컴포넌트들간의 연관관계(혹은 Dependency)는 여러가지 문제점을 가진다. 이러한 문제점은 시스템의 구동과정에서의 문제를 의미하는 것이 아니라, 개발과정에서의 여러가지 형태의 변경과정, 유지, 보수, 업그레이드 과정에서 발생하는 문제를 의미한다.
여러 컴포넌트들 가운데 특정 컴포넌트를 변경하려고 하면, 혹은 교체하려고 하면, 이 컴포넌트와 연관된 컴포넌트들에도 변경이 불가피하게 된다.
발상의 전환점은 바로 여기에 있다. 그렇다면, 컴포넌트들 간의 연관관계를 더 느슨하게 혹은 외부에서 할 수는 없을까? 그렇다. 연관관계를 컴포넌트들간에 이루어지도록 하지 말고, 컴포넌트들을 가지는 컨테이너가 연관관계를 규정하도록 하자. 그렇게 하면, 컴포넌트들 사이에는 연관관계가 발생하지 않으므로 위에서 언급된 문제들이 해결될 것이다. 이것이 바로 Inversion of Control / Dependency Injection의 핵심 개념이다.
그림1과 그림2를 비교해보면, 그림1에서는 클래스 CA가 클래스 IBImpl을 생성한다. IBImpl 클래스가 다른 클래스로 변경되면 CA에도 변경이 필요하게 된다. 반면에, 그림2에서 클래스 CA는 클래스 IBImpl과 연관관계가 없다. 단지, 인터페이스 IB만을 호출한다. 그러므로 IBImpl 클래스가 다른 클래스로 변경되어도 CA에 변경이 가해질 일이 없게 된다.
즉, DI가 갖게 되는 장점은 아래와 같다.
코드의 단순화
종속적인 코드의 최소화 (인프라 코드와 비즈니스 코드 분리)
어플리케이션을 더 쉽게 유지관리
이렇게 컨테이너에게 제어권이 넘어간것을 IoC라고 하며, 용어자체의 문제로 인해 보통은 DI라고 부르는게 요즘의 추세라고 본다.
기 존 코드가 코드안에서 객체의 생성과 소멸을 했다고 한다면, DI 개념 안에서는 객체를 생성, 파괴와 객체간의 의존관계를 컨테이너에 의해서 제어함한다는것이 핵심인것이다. 컨테이너가 객체를 제어하는 방식은 XML이 될 수도 있고 Properties로도 할 수도 있다. 스프링에서는 간단한 컨벤션 룰을 통해서 XML로 관리한다고 보면 될 것이다.
IoC의 구현방법에는 두가지가 있다. 첫째는 Dependency Lookup이다. 이 것은 컨테이너가 callback을 통해서 제공하는 lookup context를 이용해서 필요한 리소스나 오브젝트를 얻는 방식이다. EJB와 Apache Avalon의 구현방법이다. 둘째는 Dependency Injection이다. 우리가 해야할 부분은 바로 이 DI 부분이다. 이것은 비즈니스 오브젝트에 look up 코드를 사용하지 않고 컨테이너가 직접 의존구조를 오브젝트에 설정할 수 있도록 지정 해주는 방법이다. DI는 다시 Setter Injection과 Constructor Injection으로 나뉜다.
Dependency Lookup은 JNDI등을 이용하는데 오브젝트간에 decoupling을 해주는 면에서 장점이 있기는 하다. 하지만 이렇게 만들어진 오브젝트는 컨테이너 밖에서 실행 할 수 없고 JNDI외의 방법을 사용할 경우 JNDI관련 코드를 오브젝트내에 일일히 변경해 줘야 하며 테스트하기 매우 어렵고 코드양이 매우 증가하고 Strong typed가 아니므로 Object로 받아서 매번 Casting해야 하고 (그래서 primitive type은 wrapper class를 써야 하고) NamingException같은 checked exception을 처리하기 위해서 exception처리구조가 매우 복잡해지는 단점이 있다.
Dependency Injection은 각 오브젝트가 자신이 의존적인 resource와 collaborator에 대한 lookup의 책임을 가지지 않고 대신 컨테이너가 그 일을 담당하고 오브젝트 내에 주입해주는 방식이다.
따라서 lookup과 관련된 코드들이 오브젝트 내에서 완전히 사라지고 컨테이너에 의존적이지 않은 코드를 작성할 수 있다.
이는 오브젝트가 컨테이너의 존재여부를 알 필요조차도 없기 때문이다. 또 특별한 인터페이스 구현나 클래스의 상속의 필요가 없다.
최근댓글