prototype에 이어 다른 빈 스코프 중 하나인 request를 공부했다.
request 스코프는 하나의 http request와 일치하는 생명주기를 가지는 빈이다.
새로운 request가 들어오면 bean이 생성되고, request가 종료되면 빈도 따라 소멸한다.
prototype과 마찬가지로 ObjectProvider를 통해 DL할 수 있으며, 하나의 request 흐름에서는 controller단에서 getObject를 하든, service단에서 getObject를 하든 전부 같은 객체를 return받게 된다.
@Scope("request")
public class TestRequestScopeBean{
...
}...
private final ObjectProvider<TestRequestScopeBean> objectProvider; // 각 request마다 다른 객체를 리턴
...request마다 다른 객체를 얻을 수 있다는 특징 때문에 각 request마다 구분되는 log를 남기기 위해 주로 사용되는 것 같다.
request스코프 빈을 필요로하는 곳에서 매번 ObjectProvider를 주입받기 번거롭다면 스프링이 제공하는 더 나은 옵션을 통해 편하게 사용할 수 있다.
@Scope(value="request", proxyMode=ScopedProxyMode.TARGET_CLASS)
public class TestRequestScopeBean{
...
}이렇게 proxyMode를 추가하면 마치 싱글톤 스코프 객체를 주입받는 것처럼
private final TestRequestScopeBean testBean;으로 작성해도 request별로 다른 객체를 사용할 수 있다.
Class 안을 직접 까보지 않으면 singleton으로 착각하고 사용할 수 있기 때문에, 주의해서 사용해야 한다.
작동 원리는 다음과 같다.
- 실제로 주입받는 인스턴스는 TestRequestScopeBean의 인스턴스가 아닌, provider의 역할을 하는 프록시 객체의 인스턴스이다. (Configure파일을 Spring이 조작했던 것과 동일한 원리)
- 인스턴스를 사용하고자 하면 (TestRequestScopeBean의 탈을 쓰고 objectProvider 역할을 하는) testBean 으로부터 새로운 객체를 리턴받아 사용하게 된다.
다형성을 통해 사용자는 사용하고자 하는 객체의 scope가 singleton인지 request인지 알지 못해도 상관없다.
다만 위에서 언급한 것처럼 singleton으로 착각하기 쉽고 test가 어렵다는 단점 때문에 신중히 생각하고 사용하는 것이 좋겠다.
히히