스프링 기본 ‐ 섹션9

빈 스코프란?

• 빈이 존재할 수 있는 범위 -> 언제 시작/종료 되는지
• 싱글톤 - 기본, 스프링 컨테이너의 시작과 종료까지 유지
• 프로토타입 - 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위
• 웹 관련 - request / session / application

프로토타입 스코프

• 스프링 컨테이너에서 빈을 조회할 때 생성, 초기화 메서드도 실행
• 2번 조회했다면 완전히 다른 빈 2개가 생성됨
• 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리 -> 이후는 관리하지 않음
• -> 클라이언트가 관리 해야함 - 종료 메서드 등

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점

• 싱글톤 빈이 프로토타입 빈을 사용하게 되면 -> 싱글톤 빈은 생성시점에만 의존관계 주입 -> 프로토타입 빈도 그 때 생성되고 그것이 쭉 유지됨
• 그런데 프로토타입을 사용하는 목적은 그것이 아님 - 쭉 유지 X, 사용시마다 새로 생성 O

프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결

• 싱글톤 빈이 프로토타입 사용할 때 마다 스프링 컨테이너에 요청
• -> 스프링 컨테이너에 너무 종속적, 단위 테스트 어려움
• -> ObjectFactory, ObjectProvider 사용

ObjectFactory, ObjectProvider

• 프로토타입에서 사용한다 X
• 대신 조회해주는 대리자로 사용 O (DL 정도의 기능만 제공)
• 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환 -> 항상 새로운 프로토타입 빈 생성
• ObjectProvider : 지정한 빈을 컨테이너에서 대신 찾아주는 DL 서비스를 제공
• ObjectFactory : 과거 버전

JSR-330 Provider

• ObjectProvider는 스프링 의존적
• -> 자바 표준을 사용 해보자

결론 정리

• 프로토타입을 언제 쓸까요? -> 사용할 때마다 의존관계 주입 완료된 새로운 객체가 필요할 때 -> 실무 가보면 거의 쓸 일 없다 (싱글톤으로 해결 가능)
• 자바 표준 vs 스프링 의존 -> 스프링이 사실상 표준, 기능을 보고 선택하자 -> 스프링에서 표준 권장하는 기능은 그 때 표준으로 쓰면 됨

웹 스코프

• 웹에서만 작동
• 스프링이 종료까지 관리함
• request / session / application / websocket ~ request 예제 ~
• UUID : 고유한 id 확인 가능 **문제 **
• HTTP 요청이 들어오면 생성 ~ 요청 끝나면 소멸 -> 스프링 컨테이너 생성시 의존관계 주입이 안됨
• 스프링 애플리케이션을 실행하는 시점에 싱글톤 빈은 생성해서 주입이 가능
• request 스코프 빈은 아직 생성되지 않음 이 빈은 실제 고객의 요청이 와야 생성할 수 있음
• -> 실제 고객 요청이 왔을 때로 지연시켜야 함

스코프와 Provider

• ObjectProvider 덕분에 ObjectProvider.getObject() 를 호출하는 시점까지 request scope 빈의 생성을 지연
• ObjectProvider.getObject() 를 호출하시는 시점에는 HTTP 요청이 진행중이므로 request scope 빈 의 생성이 정상 처리된다.
• ObjectProvider.getObject() 를 LogDemoController , LogDemoService 에서 각각 한번씩 따로 호출해도 같은 HTTP 요청이면 같은 스프링 빈이 반환