IOC ( Inversion Of Control ) 와 IOC 컨테이너

IoC(Inversion of Control, 제어의 역전)란

 

기존에 자바 기반으로 애플리케이션을 개발할 때 자바 객체를 생성하고 서로 간의 의존관계를 연결시키는 작업에 대한

 

제어권은 보통 개발되는 애플리케이션에 있었다. 그러나 Servlet 등을 사용하는 경우 Servlet Container에게 제어권이 넘

 

어가서 객체의 생명주기(라이프사이클)을 Container들이 전담하게 된다. 이처럼 IoC에서 이야기하는 제어권의 역전이

 

란 객체의 생성에서부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀌었다는 것(IoC 컨테이너)을 의미 한다.

 

 

스프링에서의 IOC

 

스프링 프레임워크의 가장 큰 장점으로 IoC 컨테이너 기능이 부각되어 있으나, IoC 기능은 스프링 프레임워크가 탄생하

 

기 훨씬 이전부터 사용되던 개념이었다. 그러므로 "IoC 기능을 스프링 프레임워크의 장점이라고 이야기하는 것은 적합하

 

지 않다"라고 반론을 제기하면서 새로운 개념을 사용하는 것이 적합하다며 IoC를 DI라는 용어로 사용하는 것이 더 적합

 

하다고 이야기하고 있다. 이 같은 구분 이후 IoC 개념을 개발자들마다 다양한 방식으로 분류하고 있으나 다음 그림과 같

 

이 IoC와 DI 간의 관계를 분류하는 것이 일반적이다.

즉 의존성 주입(Dependecy injection)이며 어떤 객체가 클래스가 사용할 객체. 이 의존 객체에 해당하는 객체를 직접 만

 

들어서 쓰는 게 아니라 (생성자 활용 등) 주입을 받아서 사용하는 방법이다. IOC는 스프링이 없어도 가능하다. 하지만 이런

 

게 하지 않고 스프링이 제공하는 ioc 컨테이너를 사용하는 이유는 여러 dependcy injection 방법과 best practice 노하우

 

들이 쌓여있는 프레임워크이기 때문이다.

 

 

 

그렇다면 IOC 컨테이너란?

 

Spring은 하나의 프레임워크이다. 그런데 왜 Spring 컨테이너, IoC 컨테이너라는 말을 사용할까? 그렇다면 컨테이너의

 

정의는 무엇인가?

 

컨테이너는 보통 인스턴스의 생명주기를 관리하며, 생성된 인스턴스들에게 추가적인 기능을 제공하도록 하는 것이라 할

 

수 있다.

 

다시 말해, 컨테이너란 당신이 작성한 코드의 처리과정을 위임받은 독립적인 존재라고 생각하면 된다. 컨테이너는 적절한

 

설정만 되어있다면 누구의 도움 없이도 프로그래머가 작성한 코드를 스스로 참조한 뒤 알아서 객체의 생성과 소멸을 컨

 

트롤 해준다.

 

 

 

IOC 컨테이너의 핵심적인 클래스

 

1. 빈 팩토리 BeanFactory (org.springframework.beans.factory.BeanFactory) 

 

DI의 기본사항을 제공하는 가장 단순한 컨테이너

 

팩토리 디자인 패턴을 구현한 것. Bean(이하 빈) 팩토리는 빈을 생성하고 분배하는 책임을 지는 클래스

getBean()이 호출되면, 팩토리는 의존성 주입을 이용해 빈을 인스턴스 화하고 빈의 특성을 설정하기 시작. 여기서 빈의 일

 

생이 시작된다.

 

 

2. 애플리케이션 콘텍스트 ApplicationContext (org.springframework.context.factory.BeanFactory) 

 

빈 팩토리와 유사한 기능을 제공하지만 좀 더 많은 기능을 제공하는 애플리케이션 콘텍스트

 

결국 beanfactory를 상속받은 인터페이스, 따라서 ioc 컨테이너로서의 기능과 추가적으로 Environmentcapable,

 

eventpublisher, MessageSource, ResoureLoader 등의 기능을 가진다 즉 다양한 기능을 추가적으로 가진 인터페이스라고

 

보면 된다.

 

 

 

그러면 왜 ioc 컨테이너가 빈을 관리하게 했는가?

 

1. 의존성 주입

 

의존성 주입을 받으려면 빈이 돼야 한다. 대부분의 클래스는 여러 리소스에 의존한다. 의존성 주입을 하는 이유는 어떤 의

 

존하는 객체를 직접 new로 만들어서 사용하는 경우는 유연하지 못하고 테스트하기  어렵다. 즉 사용하는 리소스에 따라

 

행동을 달리해야 하는 경우 의존성 주입을 사용하는 것이 낫다.  그리고 ioc 컨테이너에서 이 의존성 주입을 제공한다.

 

2. 빈의 스코프

 

싱글톤으로 객체를 만들어서 관리하고 싶을 때 ioc 컨테이너를 사용하면 편리하다. (<-> 프로토타입)

 

싱글톤: 하나의 객체만 사용

프로토타입 : 매번 다른 객체를 사용

 

북 서비스, 받아서 사용한다면 그 인스턴스들은 항상 같은 객체일 것이며

 

메모리면에서도 효율적이고 하나의 객체를 사용하기에 런타임 시 성능 최적화에도 유리할 것이다.

 

 

3. 라이프사이클 인터페이스를 제공.

 

어떤 빈이 만들어졌을 때 부가적인 작업을 만들 수 있다.  

 

이런 것들이 우리가 직접 inversion of control 하는 코드를 직접  작성할 수 있지만 스프링이 제공하는 ioc 컨테이너를 사용하는 이유이다.

 

 

https://limmmee.tistory.com/13

 

스프링 프레임워크 2 - 컨테이너와 IoC(Inversion of Control, 제어의 역전)