[스프링 핵심 원리 - 기본편] #7. 의존관계 자동 주입 (2)

[cyzlcyzl]

조회 빈이 2개 이상

• @Autowired는 타입으로 조회하기 때문에 ac.getBean(DiscountPolicy.class)와 유사하게 동작함 (실제로는 더 많은 기능 제공)
• 타입으로 조회 시 선택된 빈이 2개 이상일 때 문제가 발생함 ➡️ NoUniqueBeanDefinitionException 오류 발생
• 구체적인 하위 타입으로 지정할 수 있지만 이는 DIP 위반이며 유연성이 떨어짐
• 이름만 다르고 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결할 수 없음

@Autowired 필드 명, @Qualifier, @Primary

@Autowired 필드 명 매칭

@Autowired는 먼저 타입 매칭을 시도하고 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

기존 코드

@Autowired
private DiscountPolicy discountPolicy

필드 명을 빈 이름으로 변경

@Autowired
private DiscountPolicy rateDiscountPolicy

@Qualifier 사용

빈 이름을 변경하는 것은 아니고 주입 시 추가 구분자를 붙여주는 방법이다.

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
@Qualifier("fixDiscountPolicy")
public class FixDiscountPolicy implements DiscountPolicy {

주입 시 @Qualifier를 붙여주고 등록한 이름을 적어준다.

생성자 자동 주입

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        @Qualifier("mainDiscountPolicy") DiscountPolicy
                                discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

수정자 자동 주입

@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy")
                                        DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

@Qualifier로 주입할 때 @Qualifier("mainDiscountPolicy")를 찾지 못하면 mainDiscountPolicy라는 이름의 스프링 빈으로 추가로 찾는다. 하지만 @Qualifier는 @Qualifier를 찾는 용도로만 사용하는 것 추천

빈 등록시에도 @Qualifier 사용 가능

@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
    return new ...
}

@Primary 사용

@Autowired 시에 빈이 여러개 매칭되면 @Primary가 우선권을 가짐

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Primary가 붙은 RateDiscountPolicy가 우선권을 갖는다.

생성자와 수정자 사용 예시

//생성자
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                        DiscountPolicy discountPolicy) {
    this.memberRepository = memberRepository;
    this.discountPolicy = discountPolicy;
}

//수정자
@Autowired
public DiscountPolicy setDiscountPolicy(DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

⭐ @Qualifier는 주입 받을 때 모든 코드에 @Qualifier를 붙여줘야 한다는 단점이 있는 반면 @Primary는 단순하다.
메인 데이터베이스 커넥션 & 서브 데이터베이스 커넥션이 있다고 가정을 하면, 메인 데이터베이스는 @Primary로 간단하게 서브 데이터베이스는 @Qualifier를 사용해 명시적으로 작성해주면 코드를 깔끔하게 유지할 수 있음 !!

• @Primary는 기본값처럼 동작
• @Qualifier는 매우 상세하게 동작

➡️ 스프링은 자동보다는 수동이, 넓은 범위의 선택권보다는 좁은 범위의 선택권이 우선순위가 높다
➡️@Qualifier가 @Primary보다 우선순위가 높음

애노테이션 직접 만들기

@Qualifier("mainDiscountPolicy") 이렇게 적으면 컴파일시 타입 체크가 안 되는 문제 발생
아래와 같이 애노테이션을 만들어서 문제를 해결할 수 있음

@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;
}

//수정자 자동 주입
@Autowired
public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy
                                                discountPolicy) {
    this.discountPolicy = discountPolicy;
}

조회한 빈이 모두 필요할 때, List, Map

public class AllBeanTest {
    
    @Test
    void findAllBean() {
        ApplicationContext ac = new
                AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000,
                "fixDiscountPolicy");
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
    
    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        public DiscountService(Map<String, DiscountPolicy> policyMap,
                               List<DiscountPolicy> policies) {
            this.policyMap = policyMap;
            this.policies = policies;
            System.out.println("policyMap = " + policyMap);
            System.out.println("policies = " + policies);
        }
        
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }
    }
}

로직 분석

• DiscountService는 Map으로 만든 모든 DiscountPolicy를 주입받음 (fixDiscountPolicy, rateDiscountPolicy 주입)
• discount() 메서드는 dicountCode로 fixDiscountPolicy가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아 실행

주입 분석

• Map<String, DiscountPolicy>: map의 키에 스프링 빈의 이름을 넣어주고 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줌
• List<DicountPolicy>: DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줌
• 해당하는 타입의 스프링 빈이 없으면 빈 컬렉션이나 Map을 주입

💡참고 스프링 컨테이너를 생성하면서 스프링 빈 등록하기

new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);

• new AnnotationConfigApplicationContext()를 통해 스프링 컨테이너 생성
• AutoAppConfig.class, DiscountService.class를 파라미터로 넘기면서 해당 클래스를 자동으로 스프링 빈 등록

자동, 수동의 올바른 실무 운영 기준

⭐ 편리한 자동 기능을 기본으로 사용하자 ⭐

• @Component, @Controller, @Service, @Repository와 같은 자동 스캔을 선호하는 추세
• @Configuration 설정 정보에 @Bean을 적고 객체를 생성하고 주입할 대상을 일일이 적어주는 과정은 번거로움

수동 빈은 언제 사용하면 좋을까?

기술 지원 빈

애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수 하기에 좋음

<애플리케이션>

• 업무 로직 빈: 컨트롤러, 서비스, 리포지토리 등이 모두 업무 로직. 비즈니스 요구사항을 개발할 때 추가되거나 변경됨
• 기술 지원 빈: 기술적이 문제나 공통 관심사(AOP) 처리, 데이터베이스 연결, 공통 로그 처리

업무 로직은 문제가 발생했을 때 어디가 문제이지 명확하게 잘 드러나지만, 기술 지원 로직은 적용이 되고 있는지 파악하기 어려운 경우가 많기 때문에 수동 빈 등록을 사용해서 명확하게 드러내는 것이 좋음

비즈니스 로직 중 다형성을 적극 활용할 때

자동 빈 등록을 사용하면 어떤 빈들이 주입될지, 각 빈들의 이름은 무엇일지 코드만 보고 쉽게 파악할 수 없고 여러 코드를 찾아봐야 함
➡️ 수동 빈으로 등록하거나
➡️ 자동 빈 등록 시 특정 패키지에 같이 묶어두는 게 좋음

@Configuration
public class DiscountPolicyConfig {

    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscountPolicy();
    }
    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
}

수동 빈 등록 시 설정 정보만 봐도 빈의 이름, 어떤 빈이 주입될지 파악할 수 있음
자동 빈 등록 시 DiscountPolicy의 구현 빈들만 따로 모아서 특정 패키지에 모아두는 것 추천

[seyxxn]

수고하셨습니당 ~!