1. 조회 빈이 2개 이상일 때
- @Autowired는 타입으로 스프링 빈을 조회한다. (ac.getBean("타입")과 유사)
- 만약 스프링 컨테이너에 동일 타입의 빈이 2개 이상 존재하려고 한다면 NoUniqueBeanDefinitionException 오류를 발생시킨다.
- 이 오류 메시지는 동일 타입의 빈이 fixDiscountPolicy, rateDiscountPolicy 2개가 발견되었다고 알려주는 메시지이다.
- 이 오류를 해결하는 방법은 여러가지가 있지만 자동 주입에서 많이 사용하는 방법이 @Qualifier와 @Primary가 있다.
2. @Qualifier와 @Primary
- 보통 조회 대상의 빈이 2개 이상이라면 크게 3가지 방법으로 해결할 수 있다.
1) @Autowired 필드 명 매칭
2) @Qualifier -> @Qualifier 끼리 매칭 -> 빈 이름 매칭
3) @Primary 사용
2-1. @Autowired 필드 명 매칭
- 간단하게 의존관계 주입할 때 인터페이스 명이 아닌 구현 클래스로 주입하는 방법이다.
- 이 방법을 사용하면 필드명이 다르기 때문에 같은 인터페이스를 가지고 있는 구현 클래스가 여러개가 있더라도 등록 및 주입할 수 있다.
* 기존 주입 방법
@Autowired
private DiscountPolicy discountPolicy
* 필드 명을 빈 이름으로 변경
@Autowired
private DiscountPolicy rateDiscountPolicy
2-2. @Qualifier 사용
- @Qualifier : 추가 구분자를 붙여주는 방식, 구분할 수 있는 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것이 아니다.
- 주입할 때 @Qualifier를 붙여주고 등록할 이름을 적어준다.
-
- 수동 빈 등록시에도 동일하게 사용할 수 있다.
@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {}
* 수동 빈 사용
@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
return new ...
}
2-3. @Primary 사용
- @Primary : 우선순위를 정하는 방법으로, @Autowired 사용시에 여러 빈이 매칭되면 @Primary가 붙은 빈이 우선권을 갖는다.
- 아래 코드에서는 @Primary가 붙은 rateDiscountPolicy가 우선권을 가진다.
@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}
@Component
public class FixDiscountPolicy implements DiscountPolicy {}
2-4 @Qualifier, @Primary의 활용
- 코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈과 코드에서 자주 사용하지 않는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 가정해보자!
- 메인 데이터베이스의 커넥션을 가져오는 스프링 빈은 @Primary를 사용하고 서브 데이터베이스의 커넥션을 가져오는 스프링빈은 @Qualifier를 사용하면 코드를 간결하게 유지할 수 있다.
- 스프링은 자동보다는 수동이, 넓은 범위보다는 좁은 범위가 우선순위가 높다. @Priamry는 넓은 범위를 체크하며 @Qualifier는 좁은 범위를 체크하기 때문에 @Qualifier의 우선순위가 더 높다.
3. Annotation 커스텀
- @Qualifier("mainDiscountPolicy") 처럼 문자로 적으면 컴파일 시 타입 체크가 되지 않는다. 따라서 Annotation을 직접 만들어서 적용하면 문제를 해결할 수 있다.
import org.springframework.beans.factory.annotation.Qualifier;
import java.lang.annotation.*;
@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}//생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
@MainDiscountPolicy DiscountPolicy discountPolicy) {
this.memberRepository = memberRepository;
this.discountPolicy = discountPolicy;
}
4. 자동 vs 수동
- 기본적으로 편리한 자동 기능을 사용하는 것이 좋다.
- 수동 빈은 설정 정보가 커지면 설정 정보를 관리하는 것 자체가 부담이 되고 자동 빈 등록을 사용해도 OCP, DIP를 모두 지킬 수 있다.
* 수동 빈은 언제 사용하면 좋을까?
- 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.
1) 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 로직 등은 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
2) 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.
- 업무 로직은 그 수가 매우 많고 어느정도 패턴이 존재한다. 이런 경우 자동을 활용하면 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉽다.
- 기술 지원 로직은 그 수가 업무 로직에 비해 적고 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다. 그래서 문제가 발생했을 때 명확하게 파악하기가 쉽지 않다. 이럴 때 수동 빈 등록을 사용하여 명확하게 드러내는 것이 좋다.
- 정리하자면 기술 지원 빈을 등록할 때는 수동 빈 등록을 사용하는 것이 유지보수성을 향상시키고 문제가 발생했을 때 빠르게 파악할 수 있다.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
본 포스팅은 인프런의 '스프링 핵심 원리 - 기본편 : 김영한 강사님'의 강의와 자료를 참고하였습니다.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
