[스프링 핵심 원리 - 기본편] 의존관계 자동 주입

다양한 의존관계 주입 방법

스프링 컨테이너의 생성과정

1. 스프링 컨테이너 생성
2. 스프링 빈 등록
3. 스프링 빈 의존관계 설정

생성자 주입

• 이름 그대로 생성자를 통해서 의존 관계를 주입 받는 방법
• 생성자 호출시점에 딱 1번만 호출되는 것이 보장
• 주로 불변, 필수 의존관계에 사용
• 생성자 주입은 스프링 빈 등록 단계에서 의존관계 주입도 같이 일어남

@Component
public class OrderServiceImpl implements OrderService {
 private final MemberRepository memberRepository;
 private final DiscountPolicy discountPolicy;
 
 @Autowired
 public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
 }
}

• 생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 (스프링 빈에만 해당)

수정자 주입(setter 주입)

• 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용
• 의존관계 설정 단계에서 발생

@Component
public class OrderServiceImpl implements OrderService {
 private MemberRepository memberRepository;
 private DiscountPolicy discountPolicy;
 
 @Autowired
 public void setMemberRepository(MemberRepository memberRepository) {
 this.memberRepository = memberRepository;
 }
 
 @Autowired
 public void setDiscountPolicy(DiscountPolicy discountPolicy) {
 this.discountPolicy = discountPolicy;
 }
}

• @Autowired 의 기본 동작은 주입할 대상이 없으면 오류가 발생
  주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정

필드 주입

• 필드에 바로 주입하는 방법
• 외부에서 변경이 불가능해서 테스트 하기 힘들다는 단점
• DI 프레임워크가 없으면 아무것도 할 수 없음
• 되도록 사용 X

@Component
public class OrderServiceImpl implements OrderService {
 @Autowired
 private MemberRepository memberRepository;
 @Autowired
 private DiscountPolicy discountPolicy;
}

일반 메서드 주입

• 일반 메서드를 통해서 주입
• 한번에 여러 필드를 주입 받을 수 있음
• 일반적으로 잘 사용하지 X

@Autowired
 public void init(MemberRepository memberRepository, DiscountPolicy 
discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
 }

참조

• 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작
• 스프링 빈이 아닌 클래스에서 @Autowired 코드를 적용하면 동작하지 않음

옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 때 @Autowired만 사용하면 required 옵션의 기본값이 true 로 되어 있어서 자동 주입 대상이 없으면 오류가 발생

@Autowired(required=false)

자동 주입할 대상이 없으면(의존관계가 없으면) 수정자 메서드 자체가 호출 안됨

        @Autowired(required = false)
        public void setNoBean1(Member noBean1){ //Member는 스프링 Bean이 아님 
            System.out.println("noBean1 = "+noBean1);
            //호출 안됨
        }

org.springframework.lang.@Nullable

자동 주입할 대상이 없으면 null이 입력

        @Autowired
        public void setNoBean2(@Nullable Member noBean2){ //Member는 스프링 Bean이 아님
            System.out.println("noBean2 = "+noBean2);
            //noBean2 = null
        }

Optional<>

자동 주입할 대상이 없으면 Optional.empty 가 입력

        @Autowired
        public void setNoBean3(Optional<Member> noBean3){ //Member는 스프링 Bean이 아님
            System.out.println("noBean3 = " + noBean3);
            //noBean3 = Optional.empty

생성자 주입을 선택하는 이유

과거에는 수정자 주입과 필드 주입을 많이 사용했지만, 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장

불변

• 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안됨(불변)
• 수정자 주입을 사용하면, set 메서드를 public으로 열어두어야 함
• 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아님

누락

• 생성자 주입을 사용하면 주입 데이터를 누락 했을 때 컴파일 오류가 발생 > 가장 발견하기 쉬워 좋은 오류
• 순수한 자바 코드를 단위 테스트 하는 경우에 수정자 의존관계인 경우 실행 전까지 오류 발견하기 어려움

final 키워드

• 생성자가 아니면 final 키워드사용 불가능
• 생성자에서 값을 넣어주거나 초기값으로 넣어줘야하고 한번 설정하면 값을 바꿀 수 없음
• 실수로 누락하거나 값이 설정되지 않으면 컴파일 오류 발생

항상 생성자 주입을 선택하고 가끔 옵션이 필요하면 수정자 주입을 선택해라. 필드 주입은 사용하지 않는게 좋다.
기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.

롬복과 최신 트랜드

롬복은 Getter와 Setter 자동으로 생성, 생성자 관련된 것 등 여러가지 편리한 기능 지원 > 기본코드의 최적화!

롬복 라이브러리 적용 방법
1. 스프링 프로젝트를 생성할 때 라이브러리를 추가해서 생성하던가 build.gradle에 라이브러리 코드 추가
2. plugin > lombok 설치
3. Preferences Annotation Processors > Enable annotation processing 체크

@RequiredArgsConstructor를 사용하면 필수값(final이 붙은 필드)을 가지고 생성자를 자동으로 만들어줌

기본 코드

@Component
public class OrderServiceImpl implements OrderService {
 private final MemberRepository memberRepository;
 private final DiscountPolicy discountPolicy;
 
 @Autowired
 public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
 }
}

Rombok 적용 코드

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
 private final MemberRepository memberRepository;
 private final DiscountPolicy discountPolicy;
}

최근에는 생성자를 딱 1개 두고, @Autowired를 생략하는 방법을 주로 사용한다. 여기에 Lombok 라이브러리의 @RequiredArgsConstructor 함께 사용하면 기능은 다 제공하면서, 코드는 깔끔하게 사용할 수 있다.

조회 빈이 2개 이상 - 문제

@Autowired 는 타입(Type)으로 조회 > 선택된 빈이 2개 이상일 때 문제가 발생

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

 public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
 }
 //어떤 DiscountPolicy 빈을 넣어줘야할지? NoUniqueBeanDefinitionException 오류 발생

• 하위 타입으로 지정할 수 도 있지만, 하위 타입으로 지정하는 것은 DIP를 위배하고 유연성이 떨어짐
• 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때 해결이 안됨

@Autowired 필드 명, @Qualifier, @Primary - 해결방법

@Autowired 필드 명 매칭

1. 타입 매칭
2. 타입이 하나면 빈 이름 안보고 그냥 매칭
3. 타입 매칭의 결과가 2개 이상일 때 필드 명 또는 파라미터 명으로 빈 이름 매칭

@Autowired private DiscountPolicy rateDiscountPolicy

@Autowired
public OrderServiceIml(MemberRepository memberRepository, DiscountPolicy rateDiscountPolicy) {
    
        this.memberRepository = memberRepository;
        this.discountPolicy = rateDiscountPolicy;
    } 

@Qualifier 사용

1. @Qualifier끼리 매칭
2. 해당 이름의 @Qualifier가 없으면 스프링 빈 이름 매칭
3. 스프링 빈 이름에도 없으면 NoSuchBeanDefinitionException 예외 발생

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

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

주입시에 @Qualifier를 붙여주고 등록한 이름 작성

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

생성자 주입, 수정자 주입, 직접 빈 등록시에도 @Qualifier 사용 가능

@Primary 사용(자주 사용)

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

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

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

• 스프링은 자동보다는 수동이, 넒은 범위의 선택권 보다는 좁은 범위의 선택권이 우선순위가 높음 > @Primary 보다 @Qualifier 가 우선권이 높음
• @Qualifier 의 단점은 주입 받을 때 모든 코드에 @Qualifier를 붙여주어야 함 > 편리하게 사용하려면 @Primary 사용

조회한 빈이 모두 필요할 때 <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,20000,"rateDiscountPolicy");

        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).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);
        }
    }
}

• Map과 List로 모든 DiscountPolicy를 주입받음 > fixDiscountPolicy, rateDiscountPolicy가 주입
  • Map<String, DiscountPolicy> : 키로 스프링 빈의 이름,
    값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 넣음
  • List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 넣음
• discount()는 discountCode로 넘어오는 이름의 스프링 빈을 찾아 실행

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

편리한 자동 기능을 기본으로 사용하는것이 좋음!

수동 빈 등록은 언제 사용할까?

• 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋음 > 스프링 부트가 아니라 내가 직접 기술 지원 체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 들어내는 것이 좋다
• 비즈니스 로직 중에서 다형성을 적극 활용할 때 사용

출처
스프링 핵심 원리 - 기본편