IoC Container ?

IoC (Inversion of Control)

한글로 번역하면 제어의 역전 이라는 말이다.

제어의 역전이라는 의미는 말 그대로 메소드나 객체의 호출작업을 개발자가 결정하는 것이 아니라 외부에서 결정되는 것을 의미한다.

 

 

스프링 애플리케이션에서는 오브젝트의 생성과 관계설정, 사용 , 제거 등의 작업을 애플리케이션 코드 대신

독립된 컨테이너가 담당한다.

즉 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고 있다고 해서 IoC라고 부른다.

Spring container == IoC Container     -----> 빈 팩토리 or 애플리케이션 컨텍스트

 

 

POJO(Plain Old Java Object ) 클래스 ? 

직역하자면 명백한 오래된 자바 객체.....뭔가 이상하다.

POJO => java beans 를 의미한다!!!

우리가 데이터를 담고 가져다 쓰기 위한 DTO를 말하는 것이였다.

다시 우리는 왜 POJO의 원칙에 따라 코드를 작성해야 하는 걸까?

-> 특정 기술과 스펙에서 독립적일뿐더러 의존관계에 있는 다른 POJO와 느슨한 결합을 갖도록 만들어야 하기에

 

지금부터 이야기 하는 부분은 스프링이 내부적으로 활용하는 빈 설정 메타정보를 담은 BeanDefinition 오브젝트를

직접 만들고 코드를 통해 IoC 컨테이너에 등록하는 방법을 설명 할 것이다!

대충 무슨이야기 인지만 알고 넘어가자!!

 

설정 메타정보

IoC 컨테이너의 가장 기초적인 역할은 오브젝트를 생성, 관리하는 것이다~!

스프링의 설정 메타정보는 XML 파일이 아니다. 스프링에 대한 대표적인 오해 중의 하나는 스프링의 설정정보는

XML로 되어 있다는 것이다. 스프링이 XML 에 담긴 내용을 읽어서 설정 메타정보로 활용하는건 맞지만, 그렇다고

스프링이 XML로만 된 설정 메타정보를 가졌다는 말은 틀렸다.

스프링의 설정 메타정보는 BeanDefinition 인터페이스로 표현되는 순수한 추상 정보이다.

즉, 애플리케이션 컨텍스트는 바로 BeanDefinition으로 만들어진 메타정보를 담은 오브젝트를 사용해 IoC와 DI

작업을 수행한다. 

결론은 "스프링의 메타정보는 특정한 파일 포맷이나 형식에 제한되거나 종속되지 않는다." 라는 것이다 .

 

 

토비스프링 그림1-3 컨테이너를 통해 애플리케이션이 만들어지는 방식

BUT,

스프링을 사용하는 개발자가 직접 ApplicationContext 인터페이스를 구현해서 사용할 일은 없을 것이다.

근데 왜 살펴봤냐고요....?? 그이유는

스프링 IoC 컨테이너는 파일 포맷이나 리소스 종류에 독립적이고 오브젝트로 표현되는 순수한 메타 정보를 사용한다는

것을 알려주기위해서!

 

이미 스프링에는 다양한 용도로 쓸 수 있는 십 여 개의 ApplicationContext 구현 클래스가 존재한다.

그런데 스프링 애플리케이션에서 직접 코드를 통해 ApplicationContext 오브젝트를 생성하는 경우는 거의 없다.

대부분 간단한 설정을 통해 ApplicationContext가 자동으로 만들어지는 방법을 사용하기 때문이다

 

컨텍스트 구성 방법

1. 서블릿 컨텍스트와 루트 애플리케이션 컨텍스트 계층구조

- 가장 기본적으로 사용되는 구성 방법이며, 나 또한 프로젝트 진행할때 이런 구성 방법으로 진행하였다.

웹 관련 Bean 은 서블릿의 컨텍스트에 두고 나머지는 루트 애플리케이션 컨텍스트에 등록 하는 방식

 

2.루트 애플리케이션 컨텍스트 단일구조

-스프링 웹 기술을시용하지 않고 서드파티 웹 프레임워크나서비스 엔진만을 사용해서 프레젠테이션

계층을 만든다면 스프링 서블릿을 둘 이유가 없다. 따라서 서블릿의 애플리케이션 컨텍스트도 사용하지

않게 된다. 이때는 루트 애플리케이선 컨텍스트만 등록해주면 된다.

 

3.서블릿 컨텍스트 단일구조

스프링 웹 기술을 사용하면서 스프링 외의 프레임워크나 서비스 엔징에서 스프링의 빈을 이용할 생각이

아니라면 루트 애플리케이션 컨텍스트를 생략 할 수도 있다 . 대신 서블릿에서 만들어지는 컨텍스트에

모든 빈을 다 등록하면 된다.