IoC와 DI(1. IoC Container란)

Spring IoC와 DI에 대해 정리.

토비의 스프링 3.1과 스프링 철저입문 도서, 타 블로그의 정리 내용을 보고 정리했습니다.

책 위주로 정리한 내용이고 풀어서 정리되어있기 때문에 간단한 정리는 타 블로그 참고를 추천드립니다.

 

Reference

• 토비의 스프링 3.1
• 스프링 철저 입문
• https://steady-coding.tistory.com/600

[Spring] Spring IoC와 DI란?

• https://dev-coco.tistory.com/80

[Spring] IoC 컨테이너 (Inversion of Control) 란?

• https://dog-developers.tistory.com/12

IoC 컨테이너와 DI(Dependency Injection)

 

 

IoC와 DI에 대한 정리는 아래와 같은 순서로 진행.

1. IoC Container란
2. IoC Container의 종류와 사용방법
3. Web Application의 IoC Container 구성
4. Bean 설정 방식, DI 방식
5. Autowiring, ComponentScan
6. Bean Scope
7. Bean 설정 분할과 profile별 설정
8. Bean 생명주기, IoC Container 종료

 

 

 

IoC 컨테이너(Inversion of Control Container)

 

스프링에서는 오브젝트의 생성과 관계 설정, 사용, 제거 등의 작업을 애플리케이션 코드 대신 독립된 컨테이너가 담당한다.

이를 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고 있다고 해서 IoC(Inversion of Control, 제어의 역전)라고 부른다.

 

객체의 생성, 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는 것을 의미하고 컴포넌트 의존관계 설정(Component dependency resolution), 설정(Configuration) 및 생명주기(Lifecycle)을 해결하기 위한 디자인 패턴이다.

 

스프링에서 객체를 생성하고 관리하고 책임지고 의존성을 관리해주는 컨테이너를 IoC 컨테이너, DI 컨테이너, 스프링 컨테이너라고 부른다.

 

컨테이너는 인스턴스 생성부터 소멸까지의 인스턴스 생명주기 관리를 개발자 대신 해준다.

그럼 개발자는 객체관리 주체가 프레임워크(컨테이너)가 되기 때문에 로직에 집중할 수 있다는 장점이 있다.

• IoC 컨테이너는 객체의 생성을 책임지고, 의존성을 관리한다.
• POJO의 생성, 초기화, 서비스, 소멸에 대한 권한을 가진다.
• 개발자들이 직접 POJO를 생성할 수 있지만 컨테이너에게 맡긴다.
• 개발자는 비즈니스 로직에만 집중할 수 있다.
• 객체 생성 코드가 없으므로 의존하는 컴포넌트간의 결합도를 낮춰 테스트가 용이하다.

 

그리고 IoC 하면 따라오는것이 DI(Dependency Injection, 의존성 주입)이다.

DI는 IoC 디자인 패턴중 하나다.

IoC는 DL(Dependency Lookup)과 DI(Dependency Injection)으로 나눌 수 있는데

DL은 저장소에 저장되어 있는 Bean에 접근하기 위해 컨테이너가 제공하는 API를 이용해 Bean을 LookUp하는 것이고

DI는 각 클래스간의 의존관계를 Bean 설정(Bean Definition) 정보를 바탕으로 컨테이너가 자동으로 연결해주는 것이다.

이렇게 DL과 DI로 나눠지지만 DI와 보통 묶어서 정리하는 이유는 DL을 사용할 경우 컨테이너 종속이 증가하기 때문에 DI를 많이 사용하기 때문이라고 한다.

 

스프링에서는 IoC를 담당하는 컨테이너를 BeanFactory, ApplicationContext라고 부리기도 한다.

오브젝트의 생성과 오브젝트 사이의 런타임 관계를 설정하는 DI 관점으로 볼 때는 컨테이너를 BeanFactory라고 하고, DI를 위한 BeanFactory에 Enterprise Application을 개발하는데 필요한 여러가지 컨테이너 기능을 추가한것을 ApplicationContext라고 부른다.

 

 

BeanFactory

• BeanFactory 계열의 인터페이스만 구현한 클래스는 단순히 컨테이너에서 객체를 생성하고 DI를 처리하는 기능만 제공한다.
• Bean을 등록, 생성, 조회, 반환 관리를 한다.
• 팩토리 디자인 패턴을 구현한 것으로 BeanFactory는 빈을 생성하고 분배하는 책임을 지는 클래스다.
• Bean을 조회할 수 있는 getBean() 메소드가 정의되어 있다.
• 보통은 BeanFactory를 바로 사용하지 않고, 이를 확장한 ApplicationContext를 사용한다.

 

ApplicationContext

• Bean을 등록, 생성, 조회, 반환 관리하는 기능을 갖고 있으며 이 기능은 BeanFactory와 같다.
• 스프링의 각종 부가 기능을 추가로 제공한다.
  • 국제화가 지원되는 텍스트 메세지를 관리해준다.
  • 이미지 같은 파일 자원을 로드할 수 있는 포괄적인 방법을 제공해준다.
  • 리스너로 등록된 빈에게 이벤트 발생을 알려준다.

 

출처 : https://dog-developers.tistory.com/12

즉, ApplicationContext는 그 자체로 IoC와 DI를 위한 BeanFactory이면서 그 이상의 기능을 가졌다고 볼 수 있다.

스프링의 IoC 컨테이너는 일반적으로 ApplicationContext를 말한다.

 

 

스프링의 BeanFactory와 ApplicationContext는 각각의 기능을 대표하는 BeanFactory와 ApplicationContext라는 두개의 인터페이스로 정의되어 있다.

그리고 ApplicationContext는 BeanFactory 인터페이스를 상속한 서브 인터페이스다.

 

public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, 
                                            HierarchicalBeanFactory, MessageSource, 
                                            ApplicationEventPublisher, ResourcePatternResolver{

}

 

토비의 스프링 3.1 예제에서는 EnvironmentCapable 인터페이스는 상속받지 않는 예제다.

5.2.3.RELEASE 기준 위와 같이 확인할 수 있는데 spring documentation에서 확인해보니 3.1부터 나온 인터페이스라고 한다.

아마 책 작성시에는 안들어가있다가 추후 추가된것이 아닌가 싶다.

이 인터페이스는 검사를 수행하는데 주로 사용되는 인터페이스라고 되어있다.

 

ListableBeanFactory와 HierarchicalBeanFactory는 BeanFactory 인터페이스의 서브 인터페이스다.

따라서 ApplicationContext는 BeanFactory 인터페이스를 상속받고 있다고 볼 수 있는 것이다.

 

IoC 컨테이너는 ApplicationContext 인터페이스를 구현한 클래스의 오브젝트를 의미한다.

스프링 애플리케이션은 최소한 하나 이상의 IoC 컨테이너, 즉 ApplicationContext 오브젝트를 갖고 있다.