본문 바로가기
개발자 공부 - 인프런 온라인 강의/스프링 핵심 원리 - 기본편

[섹션 9. 빈 스코프] 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 Provider로 문제 해결 / 인프런 김영한 스프링 핵심 원리 기본편

by easpop 2023. 10. 23.
728x90
반응형

이번 시간에는 프로토타입 스코프를 싱글톤 빈과 함께 사용할 때, Provider를 사용해서 문제를 해결하는 방법을 알아보았다.

 

먼저 프로토타입 스코프를 싱글톤 빈과 함께 사용할 때, 생기는 문제점은 아래 글을 참고!

2023.10.02 - [개발자 공부 - 인프런 온라인 강의/스프링 핵심 원리 - 기본편] - [섹션 9. 빈 스코프] 프로토타입 스코프 - 싱글톤 빈과 함께 사용시 문제점 / 인프런 김영한 스프링 핵심 원리 기본편

 

[섹션 9. 빈 스코프] 프로토타입 스코프 - 싱글톤 빈과 ᄒ

이번 시간에는 프로토타입 스코프를 싱글톤 빈과 함께 사용할 때 생기는 문제점에 대해서 알아보았다. 스프링 컨테이너에 프로토타입 스코프의 빈을 요청하면 항상 새로운 객체 인스턴스를 생

easpop.tistory.com

 

그래서 싱글톤 빈과 프로토타입 빈을 함께 사용할 때, 어떻게 하면 사용할 때 마다 항상 새로운 프로토타입 빈을 생성할 수 있을까?

 

가장 간단한 방법은 싱글톤 빈이 프로토타입을 사용할때 마다, 스프링 컨테이너에 새로 요청하는 것이다.

 

이렇게 Autowired 해서 ApplicationContext를 호출할 때마다 컨테이너에서 새로 받는 약간 무식한(?) 방법이 있다.

 

의존관계를 외부에서 주입(DI)받는게 아니라, 이렇게 직접 필요한 의존관계를 찾는 것을 Dependecy Lookup (DL), 의존관계 조회(탐색) 이라고 한다.

그런데 이렇게 스프링의 애플리케이션 컨텍스트 전체를 주입받게 되면, 스프링 컨테이너에 종속적인 코드가 되고, 단위 테스트도 어려워진다.

지금 필요한 기능은 지정한 프로토타입 빈을 컨테이너에서 대신 찾아주는 DL 정도의 기능만 제공하는 무언가가 있으면 된다.

 

스프링에서 제공하는 기능이 있는데, 그것은 ObjectFactory와 ObjectProvider이다.

 

반응형

singletonClientUsePrototype에서 프로토 타입 빈을 2번 호출해주고 count 개수를 확인해보는 코드를 작성한다.

 

테스트 결과 각각 다른 객체가 콘솔에 찍히는 것을 확인할 수 있다.

즉, 다른 객체가 두번 호출 된 것!

 

49번째 라인을 보면, getObject를 통해 호출할 때, 스프링 컨테이너에서 프로토 타입 빈을 찾아서 반환해준다.

이렇게 되면 개발자가 필요했던, 필요할 때 마다 스프링 컨테이너에서 요청하는 기능을 사용할 수 있게 되는 것이다.

과거에는 ObjectFactory가 있었는데, 여기에 몇가지 편의 기능을 추가해서 나온게 ObjectProvider이다.

 

이렇게 실행을 해보면 getObject를 통해서 항상 새로운 프로토타입 빈이 생성되는 것을 확인할 수 있다.

결국, 스프링 컨테이너에 조회하는데, PrototypeBean을 통해서 대신 조회해주는 대리자 역할을 한다고 할 수 있다.

그래서 getObject를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.

스프링이 제공하는 기능을 사용하지만, 기능이 단순하기 때문에 단위테스트를 만들거나 mock 코드를 만들기가 쉬워진다.

 

특징을 살펴보면, ObjectFactory는 기능이 단순하고, 별도의 라이브러리가 필요 없지만, 스프링에 의존적이다.

ObjectProvider는 ObjectFactory를 상속했기 때문에, 옵션, 스트림 처리 등 편의 기능이 많고, 별도 라이브러리가 필요없다. 하지만 마찬가지로 스프링에 의존적이다는 특징이 있다.

 

그래서 스프링에 의존하지 않는 기술이 나오는데, 그 방법은 JSR-330 Provider이다.

 이 방법은 자바 표준을 사용하는 방법인데, 사용을 하기 위해서는 라이브러리를 gradle에 추가를 해줘야 한다.

 

라이브러리를 받고 나서, javax.inject로 되어있는 provider를 받아야 사용해야 한다.

 

결과는 prototypeBean과 마찬가지로 provider.get 을 통해서 새로운 프로토타입 빈이 생성되어서 호출된 것을 볼 수 있다.

provider의 get()을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다(DL).

자바 표준이고, 기능이 단순하기 때문에 단위테스트를 만들거나 mock 코드를 만들기는 훨씬 쉬워진다.

Provider는 지금 딱 필요한 DL 정도의 기능만 제공한다.

 

특징을 살펴보면, get() 메소드 하나밖에 없기 때문에 기능이 매우 단순하다.

그리고 별도의 라이브러리가 필요하고, 자바 표준이므로 스프링이 아닌 다른 컨테이너에서도 사용할 수 있다.

 

그러면 프로토타입 빈을 언제 사용할까?

매번 사용할 때 마다 의존관계 주입이 완료된 새로운 객체가 필요하면 사용하면 된다.

그런데 실무에서 웹 어플리케이션을 개발해보면, 싱글톤 빈으로 대부분 문제가 해결이 되고, 프로토타입 빈을 직접적으로 사용하는 일은 매우 드물다.

싱글톤 빈에다가 추가로 사용할 일이 있으면 new 생성자를 통해서 파라미터를 넘겨서 해결하는 일이 대부분이기 때문.

 

ObjectProvider, JSR330 Provider 등은 프로토타입 뿐만 아니라 DL이 필요한 경우는 언제든지 사용 가능하다.

 

스프링을 사용하다 보면, 이 기능 뿐만 아니라 다른 기능들도 자바 표준과 스프링이 제공하는기능이 겹칠때가 많이 있는데, 대부분 스프링이 더 다양하고 편리한 기능을 제공해주기 때문에, 특별히 다른 컨테이너를 사용할 일이 없다면, 스프링이 제공하는 기능을 사용하면 된다.

 

728x90
반응형

댓글