프로토타입 빈은 DI에서는 별 사용할 가치가 없다. Scoped Proxy를 사용해봤자 소용없다. 프로토타입 빈은 생성 후에 더 이상 스프링이 관리하지 않기 때문이다. new를 대신해서 사용하는 것이기 때문에 코드에서 명시적으로 lookup을 해줘야 한다. 즉 DL을 사용해야 한다.

DL을 스프링에서 사용하는 방법은 꽤 다양하다. 전에 KSUG 포럼에 이 질문을 올린 적이 있었는데.. 그때 얼핏 정리해 방법이 7-8개쯤 되었던 것 같다.

생각난 김에 3.0에서 추가된 기능을 포함해서 간단히 정리해보자.

 

1. ApplicationContext, BeanFactory

가장 단순하고 무식한 방법이다. ApplicationContext를 직접 가져와서 getBean()을 호출하는 방법이다. DL을 설명하는 코드에는 모두 이 getBean()을 사용하는데, 사실 실전에서 이렇게 쓰라는 뜻은 아닐 것이다.

AC를 가져오는 방법은 구식인 ApplicationContextAware를 구현하는 방법과 @Autowired, @Inject, @Resource를 이용해서 직접 DI 방는 방법이 있다. 당연히 후자가 낫다.

테스트에서라면 모를까 애플리케이션 코드에서라면 절대 사용하지 않는 것이 좋다. 한심해 보이기 딱 좋다. 테스트 하기도 힘들다.

 

2. 팩토리 빈

프로토타입 빈을 사용할 코드와 AC를 디커플링 하는 가장 기본적인 아이디어는 팩토리를 끼고 팩토리 안에서 AC를 사용하도록 하는 것이다. 적어도 사용하는 쪽에서는 스프링 API가 포함되지 않기 때문에 깔끔해진다.

매번 팩토리 클래스를 직접 만들어서 빈으로 등록하는 것이 귀찮을 뿐이다. 단위테스트를 위해서라면 팩토리를 인터페이스로 만들어두어야 한다. 클래스 목을 사용해도 되긴 하지만.

 

3. ObjectFactory와 ObjectFactoryCreatingFactoryBean

ObjectFactory<T>는 스프링이 미리 정의해둔 팩토리 인터페이스이다. 장점은 팩토리 구현을 직접 할 필요가 없다는 것이다. ObjectFactory를 만들어주는 팩토리 빈인 ObjectFactoryCreatingFactoryBean을 사용하면 된다. XML에 빈으로 등록하든 @Bean으로 생성하든 하면 된다.

AC보다는 간결하지만 여전히 스프링이 제공하는 API를 쓴다는 단점이 있다. 어짜피 스프링으로 개발하는 데 그깟 스프링 API좀 쓰는 게 무슨 대수냐라고 생각한다면.. 괜찮은 방법이다. POJO 순수주의자로 완벽하게 비침투적인 코드에 집착한다면 살짝 찝찝할 수도.

 

4. ServiceLocatorFactoryBean

ObjectFactory가 스프링이 미리 제공한 인터페이스를 이용하는 것이라면 ServiceLocatorFactoryBean은 개발자가 만든 임의의 팩토리 인터페이스를 사용하게 해준다. 대신 팩토리 구현은 스프링이 알아서 해준다는 점이 장점. 미리 만들어둔 팩토리 인터페이스가 있다거나 스프링 의존적인 API를 피하고 싶다면 좋은 방법이다. 기본적으로 팩토리 메소드의 리턴타입을 보고 팩토리를 구현해주는데, 원하면 빈 이름을 지정하게 할 수도 있다.

 

5. Method Injection

lookup 메소드 자체를 스프링이 런타임 코드 구현을 통해서 넣어주는 방식이다. 스프링 비 의존적인 코드이면서 번거롭게 빈 등록도 필요없다는 점에서 매력적이지만 추상클래스로 만들어야 한다는 점이 불편하다. 특히 단위 테스트를 하려면 매번 상속을 해서 추상 메소드를 구현해줘야 하는 것이 짜증나게 느껴질 것이다. 내가 가장 많이 사용했던 DL 방식이지만 사실 지금은 제일 피하고 싶은 방법이다.

 

6. Provider

마지막은 DIJ(JSR-330)에 들어있는 Provider를 쓰는 방법이다. 3.0에서부터 지원된다. Provider는 ObjectFactory와 똑같은 개념이다. 미리 지정된 단순한 팩토리 API를 이용하는 것이다. ObjectFactory보다 나은 점은 팩토리 빈을 따로 등록할 필요가 없다는 점이다. 애노테이션에 의해서 DI할 때 Provider를 보고 스프링이 Provider를 구현한 팩토리 오브젝트를 자동으로 만들어서 주입시켜 주기 때문이다. 애노테이션 DI는 없던 1.0.2시절에 나온 ObjectFactory와는 그런면에서 대비된다. 미리 만들어진 API이지만 스프링이 아니라 표준 API인 것도 나은 점.

 

프로토타입 빈 자체를 아예 안쓰는 사람도 많다. 오브젝트 보다는 데이터 중심 아키텍처를 선호한다면 프로토타입 빈을 왜 써야하는지 이해하기도 힘들 것이다.

아무튼, 프로토타입 빈을 쓴다면 위의 6가지 방식 중에서 하나를 선택하면 된다. 1번은 왠만하면 피하는 것이 좋을 것이다. 1번을 선택하면 스프링 사용법은 얼추 알지만 스프링의 개념은 모르는 티가 팍팍 날 것이다. 단위테스트를 안할 생각이고 XML빈 설정을 써도 상관없다면 5번도 나쁘지 않다. JSR-330을 쓰고 싶지 않으면서 인터페이스 정의도 귀찮으면 3번이 좋을 것이고, JSR-330을 쓰는 데 문제가 없다면 6번이 편하다. 스프링이든 뭐든 외부 API를 쓰는데 알레르기가 있다면 4번이 좋은 선택. 괜히 일을 복잡하게 만들고 번거롭게 코드를 작성하는 것을 좋아하는 피학성 변태 개발자라면 2번도 뭐 상관없다.

Related posts:

  1. Dependecy Injection에는 Prototype Scope가 없다
  2. 유쾌한 이슈처리 재촉 메일
  3. InsideSpring (4) 빈 스캐너는 클래스를 로딩할까?
  4. Spring 3.0 (29) M2 Released

Facebook comments:

to “Prototype 빈을 위한 DL 전략”

  1. This website definitely has all of the information and facts I wanted concerning this subject and didn’t know who to ask.

  2. viagra…

    viagra…

  3. viagra online…

    viagra online…

  4. viagra where to buy viagra online https://viagrapdn.com/ # – generic viagra walmart generic viagra online for sale viagra <a href="https://viagrapdn.com/ #">buy generic 100mg viagra online</a> how much will generic viagra cost discount viagra

  5. although sites we backlink to beneath are considerably not associated to ours, we really feel they may be really really worth a go by means of, so have a look

  6. %D0%A2%D1%83%D1%80%D0%B5%D1%86%D0%BA%D0%B8%D0%B9+%D1%81%D0%B5%D1%80%D0%B8%D0%B0%D0%BB…

    %D0%A2%D1%83%D1%80%D0%B5%D1%86%D0%BA%D0%B8%D0%B9+%D1%81%D0%B5%D1%80%D0%B8%D0%B0%D0%BB…

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha