20231222 TIL

그렇다면 프로토타입 빈과 싱글톤 빈은 어떻게 함께??

프로토타입 빈을 사용할 때마다 계속 요청하기

그냥 1번 프로토타입 빈, 2번 프로토타입 빈, 3번 프로토타입 빈을 계속 요청하면 된다.
그런데 그렇게 했을 때의 문제는

1. 요청하는 만큼 코드 자체가 늘어나거나, 코드의 반복 횟수가 늘어난다.
2. 스프링에 대한 종속성이 강해지고, 단위 테스트도 어려워진다.

프로토타입 빈을 찾는 것과 같이 필요한 의존관계를 직접 찾는 것을 DL(Dependency Lookup)이라 하는데, 개발자는 간단한 검색을 간단하게 하고싶을 뿐이지 코드를 막 늘리거나 반복횟수를 늘리는 것으로 프로그램을 무겁게 하고 싶진 않을 것 같다.
다음 두 가지 방법은 필요한 DL 기능 정도만 제공한다.

ObjectProvider

@Autowired
private ObjectProvider<PrototypeBean> prototypeBeanProvider;
public int logic() {
 PrototypeBean prototypeBean = prototypeBeanProvider.getObject();
 prototypeBean.addCount();
 int count = prototypeBean.getCount();
 return count;
}

ObjectProvider 의 getObject() 를 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.
특징은
1. 스프링에 의존적이다
2. 별도의 라이브러리를 요구하지 않는다.
스프링에 의존적이라는 점이 단점이라고 할 수는 있어 보인다.

JSR-330 Provider

@Autowired
private Provider<PrototypeBean> provider;
public int logic() {
 PrototypeBean prototypeBean = provider.get();
 prototypeBean.addCount();
 int count = prototypeBean.getCount();
 return count;
}

provider 의 get() 을 호출하면 내부에서는 스프링 컨테이너를 통해 해당 빈을 찾아서 반환한다.
특징은
1. 자바 표준 기능이기 때문에 스프링 프레임워크에 의존적이지 않다. -> 다른 컨테이너에서도 사용 가능
2. 별도의 라이브러리가 필요하다.
gradle에 별도의 라이브러리를 추가해주어야 하는 점이 조금 귀찮긴 하다.

implementation "jakarta.inject:jakarta.inject-api:2.0.1"

사실 핵심은 프로토타입 빈이 아니다.

프로토타입 빈 자체는 직접적으로 잘 사용하지 않는다. 하지만 ObjectProvider나 JSR03 Provider 같은 경우에는 DL이 필요한 경우에 그냥 사용하면 된다.