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



Part III. 코어 테크놀로지

레퍼런스 문서에서 이번 Part는 스프링에서 절대적으로 중요한 기술들을 모두 다룬다.

코어 테크놀로지 중에서 가장 중요한 것은 스프링 프레임워크의 제어의 역전(IoC) 컨테이너다. 스프링 프레임워크의 IoC 컨테이너의 철저한 처리는 스프링의 관점 지향 프로그래밍(AOP) 기술이 가진 광범위한 커버리지로 밀접하게 이어진다. 스프링 프레임워크의 자체 AOP 프레임워크는 개념적으로 이해하기 쉽고 자바 엔터프라이즈 프로그래밍에서 필요한 AOP 요구사항의 80% 정도를 성공적으로 다룬다.

스프링은 AspectJ (현재 기능 면에서 가장 강력하고 자바 엔터프라이즈 영역에서 확실히 가장 발전한 AOP 구현체이다.) 와 통합도 제공한다.

마지막으로 스프링 팀은 소프트웨어 개발에 테스트 주도 개발 (TDD) 도입을 확고하게 지지한다. 그래서 스프링은 통합테스트도 지원한다. (유닛테스트에 대한 베스트 프렉티스도 제공한다.) 스프링 팀은 IoC를 제대로 사용하면 유닛 테스트와 통합 테스트를 더 쉽게 할 수 있다는 점을 깨달았다. (setter 메서드와 클래스의 적절한 생성자가 있으면 service locator registry 등을 설정하지 않아도 테스트와 쉽게 연결할 수있다.) 테스팅을 다룬 챕터에서 이 부분을 알 수 있을 것이다.

• Chapter 4, IoC 컨테이너
• Chapter 5, Resources
• Chapter 6, Validation, Data Binding, and Type Conversion
• Chapter 7, Spring Expression Language (SpEL)
• Chapter 8, Aspect Oriented Programming with Spring
• Chapter 9, Spring AOP APIs
• Chapter 10, Testing

4. IoC 컨테이너


4.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 컨테이너가 관리한다. 빈은 어플리케이션에서 수많은 객체 중 하나일 뿐이다. 컨테이너가 사용한 설정 메타데이터는 빈과 빈 사이의 의존성에 반영된다.



4.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 이 생성되고 인스턴스화 되면 완전히 설정이 완료되고 실행가능한 시스템이나 어플리케이션이 준비된다.



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

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

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


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

• 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기반의 설정데이터의 기본구조를 보여준다.

<?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를 참고해라.


4.2.2 컨테이너의 인스턴스화

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

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

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

<?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 파일이다.

<?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를 참고해라.


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

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

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

<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 빈 정의여야 한다.



4.2.3 컨테이너의 사용

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

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

// 생성과 설정 빈
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로 관리되는 빈처럼 여러 가지 웹 프레임워크 클래스에 대한 의존성 주입을 제공한다.