[Spring] 의존관계 자동 주입

 

다양한 의존관계 주입 방법

의존관계 주입에는 크게 4가지 방법이 있다.

• 생성자 주입
• 수정자 주입(setter 주입)
• 필드 주입
• 일반 메서드 주입

1. 생성자 주입

생성자를 통해서 의존관계를 주입받는 방법이다.

특징

• 생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다.
• 불변, 필수 의존관계에 사용
• 생성자가 딱 1개만 있으면@Autowired를 생략해도 자동 주입된다. 물론 스프링 빈에만 해당한다.

2. 수정자 주입(setter 주입)

setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법이다.

특징

• 선택, 변경 가능성이 있는 의존관계에 사용
• 자바 빈 프로퍼티 규약의 수정자 메서드 방식을 사용하는 방법이다.

3. 필드 주입

필드에 바로 주입하는 방법이다.

특징

• 외부에서 변경이 불가능해서 테스트하기가 힘들다는 단점이 있다.
• DI 프레임워크가 없으면 아무것도 할 수가 없다.

4. 일반 메서드 주입

일반 메서드를 통해서 주입받을 수 있다.

특징

• 한 번에 여러 필드를 주입받을 수 있다.
• 일반적으로 잘 사용하지 않는다.

 

옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때가 있는데 @Autowired만 사용하면 required 옵션의 기본값이 true로 되어있어 자동 주입 대상이 없을 경우 오류가 발생한다. 그렇기에 자동 주입 대상을 옵션으로 처리하는 방법이 있는데 아래에서 살펴보자

• @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출이 안 됨
• org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력된다.
• Optional<> : 자동 주입할 대상이 없으면 Optional.empty가 입력된다.

이렇게 자동 주입 대상을 옵션으로 처리하는 3가지 방법을 아래 예제 코드를 통해서 알아보자

public class AutoWiredTest {

    @Test
    void AutoWiredOption() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }

    static class TestBean {

        // 의존관계가 없을 시 메소드 자체가 호출이 되지 않는다.
        @Autowired(required = false)
        public void setNoBean1(Member noBean1) {
            System.out.println("noBean1 = " + noBean1);
        }

        // 의존관계가 없을 시 null로 나온다.
        @Autowired
        public void setNoBean2(@Nullable Member noBean2) {
            System.out.println("noBean2 = " + noBean2);
        }

        // 의존관계가 없을 시 Optional.empty로 나온다.
        @Autowired
        public void setNoBean3(Optional<Member> noBean3) {
            System.out.println("noBean3 = " + noBean3);
        }
    }

}

결과

테스트 코드의 결과는 위와 같은데 해당 결과에 대해 setNoBean1() 메서드는 @Autowired(required=false)이므로 호출 자체가 안 된다. setNoBean2() 메서드는 자동 주입이 없는 상황에서 @Nullable로 인해 null값이 반환되며 setNoBean3()은 Optional<>로 인해 Optional.empty를 반환하는 것을 알 수가 있다.

 

조회 빈이 2개 이상

@Autowired는 타입으로 조회하는데 선택된 빈이 2개 이상일 때 NoUniqueBeanDefinitionException 오류가 발생하는 문제가 생긴다. 이렇게 조회 대상 빈이 2개 이상일 때 해결 방법을 아래에서 알아보자

 

조회 대상 빈이 2개 이상일 때 해결 방법

• @Autowired 필드 명 매칭
• @Qualifier -> @Qualifier끼리 매칭 -> 빈 이름 매칭
• @Primary 사용

 

1. @Autowired 필드 명 매칭

@Autowired는 타입 매칭을 시도하고 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다. 필드 명 매칭은 먼저 타입 매칭을 시도하고 그 결과에 여러 빈이 있을 때 추가로 동작하는 기능이다.

 

기존 코드

@Autowired
private DiscountPolicy discountPolicy

필드 명을 빈 이름으로 변경

@Autowired
private DiscountPolicy rateDiscountPolicy

이처럼 필드 명이 rateDiscountPolicy로 정상적으로 주입이 된다.

 

2.@Qualifier를 사용

@Qualifier라는 추가 구분자를 붙여주는 방법으로 주입 시 추가적인 방법을 제공하는 것이다. -> 빈 이름을 변경하는 것은 아니다.

 

코드를 보면서 작동 방식을 확인해 보자

 

빈 등록 시 @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를 찾아서 자동으로 주입을 해준다. 그런데 @Qualifier를 사용할 때 @Qualifier를 찾지 못할 경우 @Qualifier에 설정된 이름의 스프링 빈을 추가적으로 찾는다. 또한 @Qualifier는 직접 빈 등록 시에도 사용할 수가 있다.

 

3. @Primary 사용

@Primary는 우선순위를 정하는 방법으로 @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가진다.

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

이처럼 RateDiscountPolicy에 @Primary를 설정하고 discountPolicy에 의존 관계를 주입할 경우 @Primary가 설정된 RateDiscountPolicy가 자동적으로 의존 관계가 주입된다.

 

@Primary, @Qualifier 활용

@Primary는 기본값처럼 동작하는 것이고, @Qualifier는 상세하게 동작한다. 스프링은 자동 < 수동, 넓은 범위 < 좁은 범위에 맞게 선택권의 우선순위가 정해지기 때문에 @Qualifier의 우선권이 더 높다.

 

어노테이션 직접 만들기

@Qualifier()를 사용하면 오타가 발생해도 컴파일 시 타입 체크가 안 된다. 이럴 경우 어노테이션을 만들어서 문제를 해결할 수가 있다.

  @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
  ElementType.TYPE, ElementType.ANNOTATION_TYPE})
  @Retention(RetentionPolicy.RUNTIME)
  @Documented
  @Qualifier("mainDiscountPolicy")
  public @interface MainDiscountPolicy {
  }

 

이렇게 생성된 MainDisountPolicy 어노테이션을 RateDiscountPolicy에 선언해 주면 컴파일 오류가 발생하더라도 쉽게 오류를 확인할 수가 있다.

@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}

 

이처럼 @Qualifier("mainDiscountPolicy")가 아니라 @MainDiscountPolicy를 사용해 주면 된다. 이렇게 RateDiscountPolicy에 @MainDiscountPolicy 어노테이션을 지정해 주면 @MainDiscountPolicy를 생성할 때 @Qualifier("mainDiscountPolicy")가 선언되었기 때문에 의존성을 주입할 때 구분자 역할을 해준다.

//생성자 자동 주입
@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

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우가 있다. 이럴 때 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);

        int rateDiscountPirce = discountService.discount(member, 20000, "rateDiscountPolicy");
        assertThat(rateDiscountPirce).isEqualTo(2000);
    }

    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;

        @Autowired
        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);
            return discountPolicy.discount(member, price);
        }
    }
}

결과

 

로직 분석

• DiscountService는 Map으로 모든 DiscountPolicy를 주입받는다. -> fixDiscountPolicy, rateDiscountPolicy가 주입된다.
• discount()는 discountCode 매개변수를 통해서 알맞은 스프링 빈을 찾아서 실행한다.
• 위에 두 번째 결과처럼 각각의 discountCode에 따라 할인 금액이 다르다는 것을 알 수가 있다.

주입 분석

• 위에 첫 번째 결과처럼 DiscountPolicy의 모든 타입이 Map과 List 형식으로 조회되는 것을 확인할 수가 있다.
• Map<String, DiscountPolicy> : map의 키에 스프링 빈 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
• 해당되는 타입의 스프링 빈이 없으면 빈 컬렉션이나 Map을 주입한다.

 

출처 : 인프런 우아한 형제들 최연소 기술이사 김영한의 스프링 완전 정복(스프링 핵심원리 - 기본 편)