제어의 역전 (Inversion of Control)
오브젝트가 자신이 사용할 오브젝트를 스스로 선택하지 않고 생성하지도 않고 다른 대상에게 그 제어 권한을 위임해 코드의 변경과 유지, 발전을 용이하게 하는 스프링의 주요 개발 원칙이다.
DI(Dependency Injection)
IoC는 다양한 디자인 패턴(전략 패턴, 서비스 로케이터 패턴, 팩토리 패턴, 의존관계 주입 패턴)을 활용해서 구현할 수 있는데 이 중 사용하는 객체를 생성자를 통해 주입받는 패턴을 생성자 주입 패턴이라고 한다. 생성자 주입 패턴으로 필요한 인스턴스 생성에 필요한 객체의 생성과 선택 권한을 위임해 객체 간의 컴파일 타임 의존 관계를 런타임 의존 관계로 바꿔준다.
라이브러리 VS 프레임워크
라이브러리는 애플리케이션 코드가 애플리케이션의 흐름을 직접 제어해서 필요한 기능이 있을 때 사용하는 반면에 프레임워크는 애플리케이션 코드가 프레임워크에 의해 사용되는, 다시 말해 프레임워크가 애플리케이션 흐름을 주도하는 것이 큰 차이점이다.
IoC Container
IoC 방식의 객체 관리를 담당하는 곳을 IoC Container라고 한다. 스프링에서는 IoC를 적용하기 위한 메타 정보가 필요하고 이 메타 정보는 오브젝트를 생성하고 구성할 때 사용되기 때문에 애플리케이션의 형상 정보 또는 청사진이라고 한다.
@Bean
스프링이 IoC 방식으로 관리하는 오브젝트로 모든 오브젝트가 아닌 스프링이 직접 그 생성과 제어를 담당하는 오브젝트만을 빈이라고 한다.
IoC Container
스프링의 경우 엔터프라이즈 기술을 사용하는 서버 환경이기 때문에 많은 클라이언트가 요청하는 로직에 대한 인스턴스가 매번 생성되면 서버의 부하가 발생할 수 있어 IoC컨테이너는 기본적으로 관리하는 빈 오브젝트들을 싱글톤으로 만들어서 관리해서 하나의 오브젝트를 공유해 동시에 사용하도록 한다. 뿐만 아니라 싱글톤을 직접 구현할 경우 가지고 있는 단점이 없이 스프링이 알아서 싱글톤으로 오브젝트를 만들고 관리해준다.
+ Singleton의 단점
- private 생성자로 상속이 불가능하다.
- 테스트하기 어렵다.
- 서버 환경이 여러 개의 JVM에 분산되어 설치되어 있는 경우 하나의 오브젝트 생성이 보장되지 않는다.
- 전역 상태이기 때문에 모두가 자유롭게 접근하고 수정하고 공유할 수 있는 위험성을 가지고 있다.
Bean Factory
스프링의 IoC를 담당하는 핵심 컨테이너로 빈을 등록하고 생성하고 조회하고 돌려주는 등 빈을 관리하는 기능을 담당한다.
ApplicationContext
Bean Factory를 확장한 IoC 컨테이너로 Bean Factory를 상속하고 애플리케이션 지원 기능을 포함한 추가적인 부가 서비스를 스프링에서는 인터페이스로 사용할 수 있다.
