ref. Spring Core Document
1. The IoC Container
1.1. Introduction to the Spring IoC Containers and Beans
IoC(Inversion of Control)은 DI(Dependency Injection)이라고도 알려져 있다. objects는 dependencies를 constructor argument를 통해 define 할 뿐이고, 의존성은 container가 bean을 생성할 때 주입한다.
org.springframework.beans
org.springramework.context이 패키지들이 IoC Container의 기초다.
beans package 안에 있는 BeanFactory 인터페이스가 configuration mechanism을 제공한다.
context package 안에 있는 ApplicationContext 인터페이스는 BeanFactory의 sub-interface로, 몇가지 추가 기능을 제공한다
- integration with AOP features
- message resource handling (국제화 관련 기능 제공)
- event publication
- WebApplicationContext와 같은 application-layer specific contexts
ApplicationContext가 BeanFactory의 모든것을 커버하기 때문에, 이 챕터에서는 ApplicationContext에 대해 다룰것이다.
스프링에서, Spring IoC에 의해 관리되는 객체들을 beans라고 부른다. 빈들과 그들간의 dependency는 container가 사용하는 configuration metadata에서 찾을 수 있다.
1.2. Container Overview
spring container는 configuration metadata를 읽음으로써 빈들을 관리한다. configuration metadata는 XML, Java annotation, 혹은 Java code로 표현될 수 있다.
아래와 같이, ApplicationContext 인터페이스의 몇몇 구현체는 spring으로부터 제공된다.
- ClassPathXmlApplicationContext
- FileSystemXmlApplicationContext
위 다이어그램은 스프링이 어떻게 동작하는지 가장 high level로 보여준다.
1.2.1. Configuration Metadata
configuration metadata를 생성하는 가장 traditional한 방법은 XML format을 이용하는 것이다. 최근에는, 많은 개발자들은 java-based configuration을 사용한다.
- Annotation-based configuration: Spring 2.5에서 소개되었다
- Java-based configuration: Spring 3.0에서 소개되었다. @Configuration, @Bean, @Import, @DependsOn annotations들이 new feature.
XML-based configuration은 top-level의 < beans /> element내부의 < bean /> elements 들로 구성된다. Java Configuration은 @Bean과 @Configuration을 함께 사용한다.
스프링은 AspectJ를 이용하여 domain object에 의존성을 주입한다.
1.2.2. Instantiating a Container
ApplicationContext constructor가 필요로 하는 path는 container가 configuration metadata를 어디서 load해야 하는지를 알려준다.
context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");Composing XML-based Configuration Metadata
여러개의 XML 파일로 빈을 정의하는 것은 유용하다. 각각의 XML configuration 파일은 logical layer 혹은 module을 나타낼 수 있다.
모든 XML fragments로부터 bean definitions을 불러오기 위해서, application context constructor를 사용할 수 있다. 이 constructor는 Resource locations을 인자로 받는다. 다른 방법으로는, configuration file 안에서 < import/ > element를 사용해서 다른 파일들을 불러올 수 있다. 이 때 resource의 경로는 현 파일에 대한 상대 경로이다.
< beans >
< import resource="services.xml" />
< bean id="bean1" class="..." />
< /beans >The Groovy Bean Definition DSL
bean definitions은 스프링의 Groovy Bean Definition DSL로도 가능하다. 이러한 configuration은 ".groovy" 파일에 있다. 이러한 형태의 configuration은 XML bean definitions 방법과 동일하다.
1.2.3. Using the Container
ApplicationContext는 빈들과 빈들 사이의 의존성을 관리할 수 있게 한다.
T getBean(String name, Class< T > requiredType)위 메소드를 사용하면, 빈들의 instance를 retrieve 할 수 있다.
Groovy Configuration에서도, 비슷한 방법으로 bootstrapping할 수 있다.
ApplicationContext context = new GenericGroovyApplicationContext("services.groovy");가장 유연한 것은 GenericApplicationContext로, XML configuration file을 위한 XmlBeanDefinitionReader, Groovy file을 위한 GroovyBeanDefinitionReader과 같은 reader delegates와 혼합하여 사용할 수 있다.
GenericApplicationContext context = new GenericApplicationContext();
new XmlBeanDefinitionReader(context).loadBeanDefinitions("services.xml", "daos.xml");
context.refresh();이를 이용하면 하나의 ApplicationContext에 다양한 configuration source로 부터 bean definition을 읽을 수 있다.
ApplicationContext는 getBean과 같은 bean을 retrieve하기 위한 메소드를 갖고 있다. 하지만, getBean method를 application code에서 사용하지 않고, Spring API이 빈에 대한 아무런 의존성이 없도록 하는 것이 좋다. 특정 빈에 대한 dependency는 metadata(autowiring annotation과 같은)를 통해 정의하라.
