빈의 후처리

스 프링은 빈의 생명주기에 끼어들어 빈의 설정을 재검토하거나 바꿀 수 있는 2개의 기회를 제공한다. 후처리는 어떤 이벤트가 발생한 후에 처리되는 것이라고 추측할 수 있다. 이벤트란 빈이 설정되거나 인스턴스화되는 것을 말한다. BeanPostProcessor 인터페이스는 빈이 생성되거나 묶인 후에 변경할 수 있는 두개의 기회를 제공

빈 팩토리의 후처리

BeanFactoryPostProcesor는 빈 팩토리가 빈의 정의를 로딩한 후와 빈이 인스턴스화되기 전에 빈 팩토리에 대해 후처리를 수행한다.

BeanFactoryPostProcessor의 유용한 구현 클래스 두 개

PropertyPlaceholderConfigurer

CustomEditorConfigurer

빈 묶기(Bean wiring)

XML로 묶기 : 다음을 이용해 스프링 컨테이너가 XML을 통한 빈 묶기를 지원한다.

XmlBeanFactory

ClassPathXmlApplicaionContext

FileSystemXmlApplicationContext

XmlWebApplicationContext

프로토타입과 싱글톤 비교

스프링의 모든 빈은 싱글톤. getBean()의 호출에 의해서든 묶기를 통해서든 간에, 컨테이너가 빈을 배포할 때에는 항상 그 빈의 완전히 동일한 인스턴스를 내줄 것이다.

scope="singleton"
scope="prototype"

프로토타입 빈을 정의하는 것이 유리할 때

프로토타입을 정의한다는 것은 실제 하나의 빈을 정의하는 것이 아닌, 청사진을 정의한다는 의미다. 그 다음엔 그 청사진을 바탕으로 빈들이 생성될 것이다.

프로토타입 빈은, 빈을 요청할 때마다 컨테이너가 빈의 유일한 인스턴스를 제공하기 원하면서도 그 빈의 하나 이상의 특성을 스프링을 통해 설정하고자 할 경우에 유용

프로토타입으로 정의

빈 의 이름을 사용해 getBean()을 호출할 때마다 프로토타입의 새로운 인스턴스가 생성된다. 이로 인해 데이터베이스나 네트워크 연결과 같은 제한된 자원을 사용하는 빈의 경우에는 적합하지 않다. 최소한 새로운 인스턴스가 생성될 때마다 약간의 성능 저하를 겪을 수 있기 때문에, 절대적으로 필요한 경우에만 프로토타입으로 빈을 정의하자.

초기화와 소멸

빈의 정이 내에 커스텀 init-method를 선언함으로써 빈이 인스턴스화되는 즉시 호출될 메소드를 지정할 수 있다.

커스텀 destroy -method는 빈이 컨테이너로부터 제거되기 직전에 호출될 메소드를 지정한다.

Example) 커넥션 풀링(connection pooling) 빈

public class MyConnectionPool{

public void initialize(){

//커넥션 풀 초기화

}

}

public void close(){

//연결 해제

}

}

빈의 정의는,

MyConnectionPool이 인스턴스화되자마자 initialize() 메소드가 호출,

빈이 컨테이너로부터 제거되기 직전에 close() 메소드를 호출

스프링은 또 다른 방법으로, InitializingBean과 DisposableBean이라는 동일한 역할을 하는 두개의 인터페이스를 제공한다.

이 방법은 인터페이스를 구현하는 빈을 스프링 컨테이너가 자동으로 탐지하며, 별다른 설정없이도 메소드를 호출해준다(XML 손대지 않고) 하지만, 인터페이스를 구현하게 되면, 빈은 스프링의 API에 묶이게 되어 버린다.

빈을 초기화하고 소멸시킬 때 가능하다면 init-method와 destroy-method 정의에 의존하는게 좋은 방법이다. 스프링의 인터페이스를 사용할만한 유일한 경우는 스프링 컨테이너 안에서 특별하게 사용될 프레임워크 빈을 개발할 때뿐이다.

스프링 컨테이너의 두 종류

컨 테이너는 스프링 프레임워크의 핵심이다. 스프링 컨테이너는 제어 역행(IoC)을 사용해 애플리케이션을 구성하는 컴포넌트들을 관리한다. 여기에는 협력하는 컴포넌트간의 연관관계를 생성하는 것이 포함된다. 그렇게 함으로써 객체는 좀더 명확하게 이해할 수 있고, 재사용이 가능해지며, 단위테스트가 쉬워진다.

스프링 컨테이너의 두 종류

빈 팩토리(BeanFactory)

팩토리 디자인 패턴을 구현한 것. 빈 팩토리는 빈을 생성하고 분배하는 책임을 지는 클래스

커스텀 초기화 메소드(initialization method)와 소멸 메소드(destruction method)를 호출함으로써 빈의 생명주기에 개입할 수 있다.

org .springframework.beans.factory.xml.XmlBeanFactory 가 가장 유용한데, XML 파일에 기술돼있는 정의를 바탕으로 빈을 로딩한다.

빈 팩토리에게 XML 파일로부터 빈에 대한 정의를 읽어오라고 알려준다 . 빈 팩토리가 빈 을인스턴스화하는 것은 아니고 빈은 빈 팩토리에 “늦게 ”로딩되는데, 이 말은 빈 팩토리가 빈의 정의는 즉시 로딩하는 반면, 빈 자체가 필요하게 되기 전까지는 인스턴스화 하지 않는다.

getBean()이 호출되면, 팩토리는 의존성 주입을 이용해 빈을 인스턴스화하고 빈의 특성을 설정 시작. 여기서 빈의 일생이 시작된다.

애플리케이션 컨텍스트

BeanFactory와 유사한 기능을 제공하지만 좀 더 많은 기능을 제공하는 ApplicationCont ext

이미지 등과 같은 자원을 로딩하는 범용적인 방법을 제공

리스너로 등록돼있는 빈에 이벤트를 발행할 수 있다.

구현 클래스 중 일반적으로 사용되는 세 개 의 클래스

ClassPathXmlApplicationContext : 클래스 경로에 있는 XML 파일로부터 컨텍스트 정의를 로딩하며, 컨텍스트 정의를 클래스 경로에 있는 자원으로 취급한다.

FileSystemXmlApplicationContext : 파일 시스템에 있는 XML 파일로부터 컨텍스트 정의를 로딩.

XmlWebApplicationContext : 웹 애플리케이션에 포함돼 있는 XML 파일로부터 컨텍스트 정의를 로 딩