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

[seyxxn]

7_의존관계 자동 주입 (2)

조회 빈이 2개 이상 - 문제

• @Autowired는 타입으로 조회

타입으로 조회 시 빈이 2개 이상인 문제

• DiscountPolicy에 대한 빈이 FixDiscoountPolicy, RateDiscountPolicy 2개라서 문제가 발생

• 오류메세지를 살펴보면, 하나의 빈을 기대했는데 2개가 발견되었다는 메세지가 있음
• 이때, 하위 타입으로 지정해되지만 이 방법은 DIP를 위배하고 유연성이 떨어짐

@Autowired 필드 명, @qualifier, @primary

• 위에서 살펴본 문제점을 해결할 수 있는 3가지 방법

1. @Autowired 필드 명 매칭

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

• 기존 코드

@Autowired
private DiscountPolicy discountPolicy

• 필드 명을 빈 이름으로 변경한 코드

@Autowired
private DiscountPolicy rateDiscountPolicy

🚨 에러가 나서 찾아보았더니 스프링 부트3.2 버전에서 에러 발생
여기서 해결방안을 찾았고, 컴파일러를 Gradle로 변경했더니 에러 해결 !

• @Autowired 매칭 정리
  1. 먼저 타입으로 매칭한다.
  2. 타입을 매칭했는데 결과가 없거나 두개 이상이라면 필드 명, 파라미터 명으로 빈 이름을 추가로 매칭한다.

스프링은 본인과 같은 타입이거나 그 타입의 자식들을 다 끌고 오기 떄문에..

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

• @Qulifier로 주입할 때, @Qualifier("mainDiscountPolicy")를 못찾으면 ?

  • 이런 경우에는 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾게된다.
  • 하지만 @Qualifier는 @Qualifier를 찾는 용도로만 사용하는게 명확하고 좋은 방법이다.

• 직접 빈을 등록할 때에도 @Qualifier를 사용할 수 있음

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

• @Qualifier 정리
  1. @Qualifier끼리 매칭
  2. 없다면 빈 이름 매칭
  3. 그래도 못 찾는다면 NoSuchBeanDefinitonException 예외 발생

3. 프라이머리 사용

• 우선순위를 정하는 방법

• @Autowired시에 여러 개의 빈이 매칭되면, @Primary가 붙은 빈이 우선 순위를 가짐

• rateDiscountPolicy가 우선권을 가지도록 코드 수정

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

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

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

• 코드 실행하면 문제없이 @Primary가 붙은 것이 우선 순위로 선택되어 잘 동작한다.

@primary vs @Qualifier

• 둘 중 어느 것을 사용하는 것이 좋을까?
• @Qualifier의 단점은 주입받을 때 다음과 같이 모든 코드에 @Qualifier를 붙여줘야한다는 점이다.

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

• 반면에 @Primary를 사용하면 번번히 @Qualifier를 붙일 필요가 없이, 해당 빈에만 @Primary를 붙이면 된다.

@Primary와 @Qualifier 활용

두 애노테이션을 함께 사용하여 활용할 수 있다.

• 코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈
  • @Primary를 적용하여 조회하는 곳에서 @Qualifier 지정없이 편리하게 조회할 수 있게 함
• 코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈
  • @Qualifier를 지정해서 명시적으로 획득하는 방식으로 사용하면 코드를 깔끔하게 유지할 수 있음

우선순위

• @Primary는 기본값처럼 동작하는 것
• @Qualifier는 매우 상세하게 동작
• 스프링은 자동보다는 수동이, 넓은 범위의 선택권 보다는 좁은 범위의 선택권이 우선 순위가 높음
• 따라서, @Primary보다 @Qualifier가 우선권이 높음

애노테이션 직접 만들기

@Qualifier()문자는 컴파일타임에 체크가 안된다는 문제점이 있다.
애노테이션을 만들어서 조금 더 깔끔하게 운영해보자.

• 애노테이션 생성

package hello.core.annotation;

import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.stereotype.Component;

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;
}
//수정자 자동 주입
@Autowired
public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy
discountPolicy) {
    this.discountPolicy = discountPolicy;
}

⭐ 참고

• 애노테이션에는 상속이라는 개념이 없음
• 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능임
• 스프링이 제공하는 기능을 뚜렷한 목적 없이 무분별하게 재정의하는 것은 유지보수에 더 혼란만 가중할 수 있음

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

• 의도적으로 해당 타입의 빈이 모두 필요한 경우도 있다.

  • 예를 들어, 할인 서비스를 제공하는데 클라이언트가 할인의 종류(rate, fix)를 선택할 수 있다고 가정해보자.
  • 스프링을 사용하면 소위 말하는 패턴 전략을 매우 간단하게 구현할 수 있다.

• DiscountPolicy 타입의 모든 빈들을 Map과 List의 프로퍼티에 자동으로 주입하는 테스트 코드

package hello.core.autowired;

import hello.core.AutoAppConfig;
import hello.core.discount.DiscountPolicy;
import hello.core.member.Grade;
import hello.core.member.Member;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import java.util.List;
import java.util.Map;

import static org.assertj.core.api.AssertionsForClassTypes.assertThat;

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");

        Assertions.assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);

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

    // 새로운 서비스 생성
    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        // DiscountService는 맵을 이용하여 모든 DiscountPolicy를 주입받음
        // 이때, fixDiscountPolicy와 rateDiscountPolicy가 모두 주입이 됨
        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);
        }

        // discountCode로 주입받으려는 빈을 받고, 그것을 찾아서 키 값이 같은 것을 호출함
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            return discountPolicy.discount(member, price);
        }
    }
}

• 로직 분석

  • DiscountService는 Map으로 모든 DiscountPolicy를 주입받음
    • 이때, fixDiscountPolicy와 rateDiscoountPolicy가 주입됨
  • discount() 메서드는 discountCode를 통해 'fixDiscountPolicy'가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아서 실행함. 'rateDiscountPolicy'가 넘어오면 map에서 rateDiscountPolicy 스프링 빈을 찾아서 실행함.

• 주입 분석

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

• 출력 결과

  policyMap = {fixDiscountPolicy=hello.core.discount.FixDiscountPolicy@5bf61e67, rateDiscountPolicy=hello.core.discount.RateDiscountPolicy@2c1dc8e}
  policies = [hello.core.discount.FixDiscountPolicy@5bf61e67, hello.core.discount.RateDiscountPolicy@2c1dc8e]
  
  discountCode = fixDiscountPolicy
  discountPolicy = hello.core.discount.FixDiscountPolicy@5bf61e67
  discountCode = rateDiscountPolicy
  discountPolicy = hello.core.discount.RateDiscountPolicy@2c1dc8e
  

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

• 스프링 컨테이너는 생성자에 클래스 정보를 받음
• 여기에 클래스 정보를 넘기면 해당 클래스가 스프링 빈으로 자동 등록됨

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

이 코드는 2가지로 나누어 이해할 수 있음

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

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

자동 기능을 기본으로 사용하자

• 스프링이 나오고 시간이 갈 수록 자동을 선호하는 추세
• 스프링은 @Component뿐만 아니라, @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원함
• 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계했음
• 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 것이 이상적이지만, 개발자의 입장에서 스프링 빈을 하나 등록할 때, @Component만 넣어주면 끝나는 일을 @Configuration 설정 정보에가서 @Bean을 적고, 객체를 생성하고, 주입할 대상을 일일이 적어주는 과정은 상당히 번거로움
• 또한, 관리할 빈이 많아서 설정 정보가 커지면 설정 정보를 관리하는 것 자체가 부담이 됨
• 그리고 결정적으로, 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있음

수동 빈 등록은 언제 사용하는 것이 좋을까?

1. 기술 지원 빈 등록할 때

애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.

• 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리들이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
  • 업무로직은 숫자도 많고, 한번 개발해야하면 컨트롤러, 서비스, 리포지토리 처럼 어느정도 유사한 패턴이 존재
  • 이런경우 자동 기능을 적극 사용하는 것이 좋음
  • 문제가 발생해도 어떤 곳에서 문제가 발생하였는지 명확하게 파악하기 쉬움
• 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리처럼 업무 로직을 지원하지 귀한 하부 기술이나 공통 기술들이다.
  • 업무 로직과 비교하여 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미침
  • 업무 로직은 문제가 발생했을 때 어디가 문제인지 명확하게 잘 드러나지만, 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 조차 파악하지 어려운 경우가 많음.
  • 따라서 기술 지원은 수동 빈 등록을 사용하여서 명확하게 드러내는 것이 좋음

✅ 결론

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

2. 비즈니스 로직 중에서 다형성을 적극 활용할 때, 수동 빈 등록을 하는 것이 유리

조회한 빈이 모두 필요할 때, -> List, Map 예시를 다시 보자.
DiscountService가 의존관계 자동 주입으로 Map<String, DiscountPolicy>을 주입받고 있다.

• 여기서 DiscountPolicy에 어떤 빈들이 주입되는지 알 수 있을까?
  수동 빈 등록이 아닌 자동 빈 등록을 하고 있기 때문에 여러 코드를 살펴봐야 파악이 가능하다
  따라서, 이런 경우 수동 빈으로 등록하거나, 자동으로 한다면 특정 패키지에 같이 묶어두는 것이 좋다.

• 특정 패키지에 묶은 사진
  

• 수동으로 등록한 코드

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

  • 이렇게 수동으로 등록하면, 이 설정 정보만 보아도 빈의 이름은 물론이고 어떤 빈들이 주입될지를 한 눈에 파악할 수 있다.ㅏ

정리

• 편리한 자동 기능을 기본으로 사용하자
• 직접 등록하는 기술 지원 객체는 수동 등록
• 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자