IoC 컨테이너 1장

이 문서는 개인적인 목적이나 배포하기 위해서 복사할 수 있다. 출력물이든 디지털 문서든 각 복사본에 어떤 비용도 청구할 수 없고 모든 복사본에는 이 카피라이트 문구가 있어야 한다.

IoC 컨테이너


1 Spring IoC 컨테이너와 빈즈(beans)의 도입

이번 챕터는 제어의 역전 (IoC) 원리에 대한 스프링 프레임워크의 구현체에 대해 설명한다. IoC는 의존성 주입 (DI) 으로도 알려다. 이는 객체가 함께 동작해야 하는 의존성을 정의하는 처리 과정이다. IoC는 생성자 아규먼트나 팩토리 메서드의 아규먼트 또는 객체 인스턴스 후에 설정된 프로퍼티나 팩토리 메서드에서 리턴받은 값으로 정의한다. 그다음 컨테이너는 빈이 생성될 때 의존성을 주입한다. 이 처리 과정은 빈 스스로 인스턴스화 하는 과정을 제어하거나 직접 클래스의 생성자를 사용해서 의존성을 정의하거나 또는 서비스 로케이터 패턴 같은 메니즘과 근본적으로 정반대이므로 제어의 역전 (IoC)이라고 이름 붙였다.

org.springframework.beans와 org.springframework.context 패키지는 스프링 프레임워크 IoC 컨테이너의 기반이다. BeanFactory 인터페이스는 어떤 타입의 객체도 다룰 수 있는 향상된 설정 메카니즘을 제공한다. ApplicationContext는 BeanFactory의 서브 인터페이스다. ApplicationContext는 스프링의 AOP기능, 메시지 리소스 핸들링 (국제화(i18n)를 사용하려고), 이벤트 발생, 웹 어플리케이션의 WebApplicationContext같은 어플리케이션 계층에서 지정한 컨텍스트와 더 쉽게 통합할 수 있게 한다.

간단히 말하면 BeanFactory는 설정 프레임워크와 기본적인 기능을 제공하고 ApplicationContext는 에 엔터프라이즈급에 가까운 기능을 추가한다. ApplicationContext 는 BeanFactory의 슈퍼셋이고 이 챕터에서는 전적으로 스프링 IoC 컨테이너를 설명하는 데만 사용한다. ApplicationContext 대신 BeanFactory를 사용하는 방법에 대해 더 자세한 내용을 알고 싶다면 Section 4.15, “The BeanFactory”를 참고해라.

스프링에서 어플리케이션의 중추가 되고 스프링 IoC 컨테이너가 관리하는 객체를 빈(bean)이라고 부른다. 빈은 인스턴스화 되고 결집한 객체로 스프링 IoC 컨테이너가 관리한다. 빈은 어플리케이션에서 수많은 객체 중 하나일 뿐이다. 컨테이너가 사용한 설정 메타데이터는 빈과 빈 사이의 의존성에 반영된다.



2 컨테이너 개요

org.springframework.context.ApplicationContext 인터페이스는 스프링 IoC 컨테이너를 나타내며 앞에서 언급한 빈을 인스턴스화하고 설정하고 조합하는 데 책임이 있다. 컨테이너는 어떤 객체를 인스턴스로 만들고 설정하고 조합해야 하는지를 설정 메타데이터에서 알아낸다. 설정 메타데이터는 XML이나 자바 어노테이션, 자바 코드로 나타낸다. 설정 메타데이터는 어플리케이션을 구성하는 객체들을 나타내고 그러한 객체들 사이의 풍부한 상호 의존성을 나타낸다.

ApplicationContext 인터페이스의 다양한 구현체는 스프링 밖에서 제공된다. 단독 어플리케이션에서는 일반적으로 ClassPathXmlApplicationContext나 FileSystemXmlApplicationContext의 인스턴스를 생성한다. XML이 설정 메타데이터를 정의하는 보편적인 포맷이 되었지만, 자바 어노테이션이나 메타데이터 형식의 코드로 컨테이너에 설정을 알려줄 수 있다. 이러한 추가적인 메타데이터 포맷을 선언적으로 지원하도록 하는 소량의 XML 설정만 제공하면 된다.

대부분의 어플리케이션 시나리오에서 스프링 IoC 컨테이너의 인스턴스를 만드는 명시적인 사용자 코드는 필요하지 않다. 예를 들어 웹 어플리케이션 시나리오에서 어플리케이션의 web.xml에서 8줄 정도의 J2EE 웹 디스크립터 XML만으로도 보통 충분할 것이다.(Section 4.14.4, “Convenient ApplicationContext instantiation for web applications” 참고) 이클립스 기반의 개발환경인 SpringSource Tool Suite나 Spring Roo를 사용한다면 이러한 설정은 몇 번의 마우스 클릭이나 키보드 입력만으로도 생성할 수 있다.

다음 다이어그은 스프링이 어떻게 어떻게 동작하는지 보여준다. 어플리케이션의 클래스들은 설정 메타 데이터와 결합한다. 그래서 ApplicationContext 이 생성되고 인스턴스화 되면 완전히 설정이 완료되고 실행가능한 시스템이나 어플리케이션이 준비된다.

Spring IoC 컨테이너

2.1 설정 메타데이터(Configuration metadata)

앞의 다이어그램에서 봤듯이 스프링 IoC 컨테이너는 설정 메타데이터 형식을 받아들인다. 이 설정 메타데이터를 통해 어플리케이션 개발자는 스프링 컨테이너가 어플리케이션의 객체를 어떻게 인스턴스화하고 설정하고 조합해야 하는지 지시할 수 있다.

설정 메타데이터는 전통적으로 간단하고 직관적인 XML 포맷을 사용한다. 이 챕터에서도 스프링 IoC 컨테이너의 핵심 개념과 기능을 설명하기 위해서 XML을 사용한다.

Note

XML기반의 메타데이터는 설정 메타데이터를 위한 유일한 형식이 아니다. 스프링 IoC 컨테이너 자체도 실제 작성된 설정 메타데이터의 형식과 완전히 분리되어 있다.

스프링 컨테이너에 다른 형식의 메타데이터를 사용하는 방법에 대해서는 다음을 참고해라.

• Annotation-based configuration: 스프링 2.5에서 도입된 어노테이션 기반의 설정 메타데이터 지원.
• Java-based configuration: 스프링 3.0을 시작하면서 Spring JavaConfig 프로젝트의 많은 기능이 스프링 프레임워크의 핵심부분이 되었다. 그러므로 XML파일 대신에 자바로 어플리케이션 클래스에 대한 빈을 외부에서 정의할 수 있다. 이 기능을 사용하려면 @Configuration, @Bean, @Import, @DependsOn 봐라.

스프링의 설정은 컨테이너가 반드시 관리해야 하는 최소한 하나 이상의 빈 정의로 이루어진다. XML기반의 설정 메타데이터는 최상위 <beans/> 엘리먼트 안에 <bean/> 엘리먼트로 이러한 빈을 설정한다.

이러한 빈 정의들은 어플리케이션을 구성하는 실제 객체들과 대응된다. 일반적으로 서비스계층 객체, 데이터 접근 객체(DAO), Struts Action 인스턴스같은 프리젠테이션 객체, Hibernate SessionFactories같은 인프라스트럭처 객체, JMS Queues등을 정의한다. 보통 이는 보통 도메인 객체를 생성하고 로드하는 DAO와 비즈니스 로직에 대한 책임이 있기 때문에 컨테이너에서 세분화된 도메인 객체를 설정하지 않는다. 하지만 IoC 컨테이너의 제어범위 밖에서 생성된 객체를 설정하기 위해 AspectJ를 스프링과 통합할 수 있다. Using AspectJ to dependency-inject domain objects with Spring를 참고해라.

다음 예제는 XML기반의 설정데이터의 기본구조를 보여준다.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="http://www.springframework.org/schema/beans            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">     <bean id="..." class="...">     <!-- 이 빈에 대한 추가적인 협력 객체나 설정은 여기에 작성한다 -->   </bean>     <bean id="..." class="...">     <!-- 이 빈에 대한 추가적인 협력 객체나 설정은 여기에 작성한다 -->   </bean>     <!-- 추가적인 빈 정의는 여기에 작성한다 -->   </beans>

id 속성은 개별 빈 정의를 구분하기 위해 사용하는 문자열이다. class 속성은 빈의 타입을 정의하고 정규화된(fully qualified) 클래스 명을 사용한다. id 속성의 값은 협력 객체를 참조한다. 협력 객체를 참조하는 XML은 이 예제에 없다. 더 자세한 정보는 Dependencies를 참고해라.


2.2 컨테이너의 인스턴스화

스프링 IoC 컨테이너의 인스턴스화는 이해하기 쉽다. ApplicationContext 생성자에 제공한 위치 경로는 사실 리소스에 대한 문자열이다. 컨테이너는 이 경로로 로컬파일 시스템 같은 다양한 외부리소스나 자바 CLASSPATH 등에서 설정 메타데이터를 로드한다.

?

1	ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"});

Note

스프링의 IoC 컨테이너를 공부하고 나면 Chapter 5, Resources에서 설명하는 스프링의 Resource에 대해서 궁금해질 것이다. Resource는 URI 문법으로 정의된 위치에서 입스트림을 읽는 편리한 메니즘을 제공한다. 특히, Resource 경로는 Section 5.7, “Application contexts and Resource paths”에서 설명하는 어플리케이션 컨텐스트를 구성하는 데 사용한다.

다음 예제는 서비스 계층 객체 (services.xml)의 설정파일이다.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="http://www.springframework.org/schema/beans            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">     <!-- 서비스 -->     <bean id="petStore"         class="org.springframework.samples.jpetstore.services.PetStoreServiceImpl">     <property name="accountDao" ref="accountDao"/>     <property name="itemDao" ref="itemDao"/>     <!-- 이 빈에 대한 추가적인 협력 객체나 설정은 여기에 작성한다 -->   </bean>     <!-- 서비스에 대한 추가적인 빈 정의는 여기에 작성한다 -->   </beans>

다음 예제는 데이터 접근 객체인 daos.xml 파일이다.

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans"        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"        xsi:schemaLocation="http://www.springframework.org/schema/beans            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">     <bean id="accountDao"       class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapAccountDao">     <!-- 이 빈에 대한 추가적인 협력 객체나 설정은 여기에 작성한다 -->   </bean>     <bean id="itemDao" class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapItemDao">     <!-- 이 빈에 대한 추가적인 협력 객체나 설정은 여기에 작성한다 -->   </bean>     <!-- 데이터 접근 객체에 대한 추가적인 빈 정의는 여기에 작성한다 -->   </beans>

앞의 예제에서 서비스계층은 PetStoreServiceImpl 클래스로 이루어져 있고 SqlMapAccountDao와 SqlMapItemDao 타입의 두 데이터 접근 객체들은 iBatis 객체/관계 매핑(Object/Relational mapping) 프레임워크에 기반을 둔다. property name 요소는 JavaBean 프로퍼티의 이름을 참조한다. ref 요소는 또 다른 빈 정의의 이름을 참조한다. id와 ref 요소의 결합은 협력 객체들 사이의 의존성을 나타낸다. 객체의 의존성을 설정하는 방법에 대한 자세한 내용은 Dependencies를 참고해라.


2.2.1 XML기반의 설정 메타데이터 구성

빈 정의를 여러 XML 파일에 하는 것은 유용할 수 있다. 때때로 개별 XML 설정파일은 아키텍처상의 논리적인 계층이나 모듈을 나타낸다.

어플리케이션 컨텍스트 생성자를 이러한 XML 파일들로부터 빈 정의를 로드하는데 사용할 수 있다. 이 생성자는 이전 섹션에서 보여준 것처럼 여러 Resource의 위치를 받을 수 있다. 아니면 하나 이상의 <import/> 요소를 사용해서 다른 파일의 빈 정의를 로드할 수 있다. 예를 들면 다음과 같다.

?

1 2 3 4 5 6 7 8 9 10

<beans>       <import resource="services.xml"/>     <import resource="resources/messageSource.xml"/>     <import resource="/resources/themeSource.xml"/>       <bean id="bean1" class="..."/>     <bean id="bean2" class="..."/>   </beans>

앞의 예제에서는 services.xml, messageSource.xml, themeSource.xml 의 3개 파일에서 외부 빈 정의를 로드했다. 모든 위치 경로는 임포트하는 파일의 상대경로이므로 services.xml는 반드시 같은 디렉터리에 있거나 같은 클래스패스 경로에 있어야 한다. 그리고 messageSource.xml 와 themeSource.xml는 임포트하는 파일 하위에 resources 위치에 있어야 한다. 이 예제에서 보듯이 맨 앞의 슬래시(/)는 무시되고 경로는 상대경로가 되므로 맨 앞에 슬래시를 사용하지 않는 것이 더 좋은 형식이다. 임포트된 파일의 내용은 최상위에 <beans/>가 있는 스프링 스키마나 DTD를 따르는 유효한 XML 빈 정의여야 한다.

Note

"../"를 사용해서 부모 디렉터리의 파일을 참조하는 것도 가능하지만 별로 권하지 않는다. 부모 디렉터리를 참조하면 현재 어플리케이션 밖에 있는 파일에 대한 의존성을 만든다. 특히 이러한 참조는 "가장 가까운" 클래스패스 루트를 선택하고 루트의 부모 디렉터리를 검색하는 런타임 처리인 "classpath:" URL(예를 들면 "classpath:../services.xml")에서는 사용하지 말아야 한다. 클래스패스 설정을 변경하면 다른 디렉리나 잘못된 디렉터리를 선택할 수 있다.

항상 상대경로 대신 정규화된(fully qualified) 리소스 경로를 사용할 수 있다. 예를 들면 "file:C:/config/services.xml"나 "classpath:/config/services.xml"와 같은 형식이다. 하지만 절대경로를 사용하면 어플리케이션 설정이 특정 절대경로에 대한 깊은 결합도가 생긴다는 것을 알아야 한다. 보통 이러한 절대 경로를 우회하는 방법을 더 선호한다. 예를 들면 "${...}" 플레이스홀더를 사용해서 런타임시에 JVM 시스템 프로퍼티로 교체한다.

2.3 컨테이너의 사용

ApplicationContext는 여러 빈의 등록과 빈의 의존성을 유지하는 향상된 팩토리 기능을 제공하는 인터페이스다. T getBean(Stringname, Class<T> requiredType) 메서드를 사용하면 빈의 인스턴스를 얻을 수 있다.

ApplicationContext는 다음과 같이 빈 정의를 읽고 빈에 접근할 수 있게 한다.

?

1 2 3 4 5 6 7 8

// 생성과 설정 빈 ApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"});   // 설정된 인스턴스 획득 PetStoreServiceImpl service = context.getBean("petStore", PetStoreServiceImpl.class);   // 설정된 인스턴스 사용 List userList service.getUsernameList();

getBean()를 사용해서 빈의 인스턴스를 얻는다. ApplicationContext 인터페이스에는 빈을 얻어오는 몇 가지 메서드가 더 있지만, 이상적으로는 어플리케이션 코드는 이러한 메서드를 사용하지 말아야 한다. 사실 어플리케이션 코드는 getBean() 메서드를 전혀 호출하지 말아야 한다. 그래서 스프링 API에 대한 의존성을 전혀 갖지 말아야 한다. 예를 들어 웹 프레임워크에 대한 스프링의 통합은 컨트롤러와 JSF로 관리되는 빈처럼 여러 가지 웹 프레임워크 클래스에 대한 의존성 주입을 제공한다.