스프링은 Ioc 컨테이너가 객체를 관리하는 프레임워크임을 아는게 중요하다.
스프링의 특징
프레임 워크 vs 라이브러리
스프링은 프레임워크이고 라이브러리와의 차이점이 중요하다.
가장 큰 차이점은 제어의 흐름을 누가 갖고 있느냐인데
프레임워크는 사용자의 코드가 프레임워크의 흐름에서 필요할 때 불러 사용하고
라이브러리는 사용자의 코드 흐름에 맞춰 사용자가 필요할 때 라이브러리를 불러 사용한다.
이와 같이 개발자가 작성한 객체나 메서드의 제어를 프레임워크가 하는 설계 원칙을 Ioc(Inversion of Control)이라고 한다.
IoC(Inversion of Control) 실현을 위한 DI(Dependency Injection)
DI는 의존관계 주입이라고 하고, 스프링을 사용해봤다면 @Autowired로 많이들 접해봤을 것이다.
보통 의존성을 외부로부터 주입받고, 해당 클래스 내에서는 의존성을 생각하지 않고 해당 클래스의 로직에 집중할 수 있게 사용하는 것을 DI 라고 한다.
이처럼 DI를 사용할 때 보통 DIP(의존성 역전)까지 적용해 추상화 된 인터페이스나 상위클래스에 의존하면 사용하는 객체간의 결합을 느슨하게 만들어 유연하고 확장성을 넓힐 수 있다.
스프링 IoC 컨테이너
스프링 프레임워크의 객체의 구성 메타 데이터를 읽어 객체의 생명주기를 관리하고 의존성을 관리한다.
인스턴스 생성, 소멸 관리와 의존성 관리를 프레임워크가 대신 해주기 때문에 개발자는 로직에 집중 할 수 있다.
객체 관리를 프레임워크가 해주기 때문에 쉬운 테스트도 가능하다.
스프링 컨테이너 상속도
BeanFactory
- 스프링 컨테이너의 최상위 인터페이스
- 스프링 빈을 관리하고 조회하는 역할을 담당
- getBean()을 제공
ApplicationContext
- BeanFactory 기능을 상속받아 제공
- 메시지 소스를 활용한 국제화 기능을 제공
- 로컬, 개발, 운영 등의 환경변수를 구분해서 처리
- 이벤트를 발행하고 구독하는 모델을 편리하게 지원
- 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회 하는 기능을 지원
스프링 빈
스프링 컨테이너에서 관리되는 객체
스프링 빈 이벤트 라이플 사이클
스프링 컨테이너 생성 > 스프링 빈 생성(객체 생성 + property 설정) > 의존 설정 > 초기화 > 사용 > 소멸
객체 생성 + property 설정
Annotation, Java config, Xml로부터 Bean Definition를 얻어와 컨테이너에 빈으로 생성한다.
의존 설정
컨테이너에서 getBean으로 빈을 가져와 수동으로 주입하거나 @Autowired를 통한 자동 주입을 통해 의존성 설정을 한다.
스프링 빈 초기화 ~ 소멸
스프링 빈은 객체를 생성하고 의존설정이 끝난 다음 필요한 데이터를 사용할 수 있는 준비가 완료되어 빈 초기화는 이전단계가 모두 완료 되고 호출해야하는데 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드로 초기화 시점을, 스프링 컨테이너가 종료되기 직전에 소멸 콜백을 준다.
초기화
컨테이너에 올라간 모든 객체가 필요한 것은 아니지만 커넥션 풀처럼 초기화를 거침
소멸
스프링 컨테이너 종료 되기 전 빈 소멸 콜백 이후 컨테이너 소멸
빈 스코프
싱글톤
기본 설정인 타입으로 스프링 컨테이너 생성 이후 생성되고, 컨테이너 소멸전에 소멸되는 넓은 범위의 스코프
전역적으로 사용되기 때문에 상태를 가지면 동기화 문제가 일어날 수 있으므로 빈은 무상태(No Field, Yes Method)로 설계해야한다.
프로토타입
요청 될때 빈이 생성되서 의존설정, 초기화를 걸쳐 클라이언트에게 반환되고 컨테이너에서 삭제하기 때문에 프로토 타입 빈은 클라이언트가 관리해야한다.
웹
request : HTTP 요청이 들어오고 나갈 때 까지 유지되는 스코프
session : HTTP Session과 동일한 생명주기를 가지는 스코프
application : 서블릿 컨텍스트와 동일한 생명주기를 가지는 스코프
websocket : 웹소켓과 동일한 생명주기를 가지는 스코프
