본문 바로가기

Spring

[인프런 강의 복습] 스프링 핵심 원리 - 의존관계 자동 주입

■ 의존관계 주입 방법

@Autowired의 기본 동작은 주입할 대상이 없으면 오류가 발생
주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false)로 지정
의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작


1) 생성자 주입

- 생성자를 통해서 의존 관계를 주입 받는 방법
- 앞선 예제가 생성자를 통한 의존 관계를 주입했다.
- 생성자 호출 시점에 딱 1번만 호출되는 것이 보장
- 불변, 필수 의존관계에 사용
- 생성자가 딱 1개만 있을 경우, @Autowired를 생략해도 자동으로 의존관계가 주입된다. (스프링 빈에만 해당)

2) 수정자 주입(setter 주입)
- setter라 불리는 필드의 값을 변경하는 수정자 메서드를 통해서 의존 관계를 주입하는 방법
- 선택, 변경 가능성이 있는 의존관계에 사용
3) 필드 주입
- 필드에 바로 의존 관계를 주입하는 방법
- 외부에서 변경이 불가능해서 테스트가 어렵다. 
- 사용하지 말자!

4) 일반 메서드 주입
- 일반 메서드를 통해서 의존 관계를 주입받는 방법
- 한번에 여러 필드를 주입 받을 수 있다.
- 일반적으로 잘 사용하지 X

 

자바빈 프로퍼티

자바에서는 필드의 값을 직접 변경하지 않고, setXXX, getXXX 라는 메서드를 통해서 값을 읽거나 수정하는 규칙을 만들었다.
이를 자바빈 프로퍼티 규약이라고 지칭

 

■ @Autowired의 옵션 처리

주입할 스프링 빈이 없어도 동작해야 할 경우가 있다.
@Autowired는 required 옵션의 기본 값이 true로 되어 있어서 자동 주입 대상이 없을 경우, 오류를 발생

[자동 주입 대상을 옵션으로 처리하는 방법]
1) @Autowired(required=false)
- 자동 주입할 대상이 없으면 수정자 메서드(set 메서드) 자체가 호출 되지 X

2) org.springframework.lang.@Nullbale
- 자동 주입할 대상이 없으면 null이 입력

3) Optional<>
- java 8에서 제공
- 자동 주입할 대상이 없으면 Optional.empty가 입력

 

■ 자동 주입 대상 옵션 예제

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 org.springframework.context.annotation.Configuration;
import org.springframework.lang.Nullable;
import org.springframework.stereotype.Component;
import soyeon.study.inflearn.member.Member;

import java.util.Optional;

public class AutowiredTest {

    @Test
    void autowiredOption() {
        // AnnotationConfigApplicationContext 클래스의 파라미터로 넘김 
        // 클래스(TestBeanConfig)
        // 스프링 컨테이너에 스프링 빈으로 등록이 된다.
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestBeanConfig.class);
    }

    static class TestBeanConfig {

        // 의존관계를 주입할 대상이 없을 경우, 처리할 수 있는 다양한 옵션
        // Member는 스프링 빈이 아니기 때문에 의존관계를 주입할 대상이 없다.
        @Autowired(required = false)
        public void setBean1(Member member){
            System.out.println("call TestBean.setBean1 = " + member);
        }

        @Autowired
        public void setBean2(@Nullable Member member){
            System.out.println("call TestBean.setBean2 = " + member);
        }

        @Autowired
        public void setBean3(Optional<Member> member){
            System.out.println("call TestBean.setBean3" + member);
        }
    }
}

 

■ 생성자 주입을 선택해라!

최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장

1) 불변
- 대부분의 의존 관계 주입은 한번 일어나면 애플리케이션 종료 시점까지 의존 관계를 변경할 일이 X
- 수정자 주입을 사용하면 setXXX 메서드를 public으로 열어두어야 한다.
- 누군가 실수로 변경될 수도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 X
- 생성자 주입은 객체를 생성할 때, 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

2) 누락
- 수정자 주입을 통해 의존 관계를 주입하는 경우 
- @Autowired가 프레임워크 안에서 동작할 때는 의존관계가 없을 경우 오류를 발생하지만, 프레임워크 없이 순수한 자바 코드로만 단위 테스트를 할 경우 코드 상의 오류는 발생하지 않지만, 실행시켜보면 NPE(Null Point Exception)이 발생한다.
- memberRepository, discountPolicy 모두 의존관계 주입이 누락되었기 때문이다.
- 생성자 주입을 사용하면, OrderService를 객체를 생성 시 컴파일 오류가 발생할 것이다. 또한 IDE에서 바로 어떤 값을 필수로 주입해야 하는지도 알 수 있다.

3) final 키워드 사용
- 생성자 주입을 사용하면 필드에 final 키워드를 사용할 수 있다. 
- 생성자에서 초기화되지 않은 오류를 컴파일 시점에 막아준다. (누락의 위험성을 미리 방지해준다)

 

■ 롬복과 최신 트랜드

1) 롬복 라이브러리를 적용 
- 롬복 라이브러리가 제공하는 @RequiredArgsConstructor 어노테이션을 사용하면, final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다. 
- 코드가 훨씬 더 간결해진다. 

- 롬복은 자바의 어노테이션 프로세스라는 기능을 이용해서 컴파일 시점에 생성자 코드를 자동으로 생성해준다.

 

■ @Autowired, @Qualifier, @Primary

1) 조회 빈이 2개 이상일 경우, 문제점
- @Autowired는 스프링 빈의 타입(Type)으로 조회를 해서 자동주입한다.
- DiscountPolicy 타입으로 스프링 빈을 조회하여 주입하면, 하위 타입인 FixedDiscountPolicy, RateDiscountPolicy 두개의 스프링 빈이 조회되어 오류가 발생된다.
- NoUniqueBeanDefinitionException 오류 발생

2) 조회 빈이 2개 이상일 경우, 해결방법
- @Autowired 필드 명 매칭
- @Qualifier 어노테이션 사용
- @Primary 어노테이션 사용

2-1) @Autowired 필드 명 매칭 예시
- @Autowired는 타입 매칭을 시도하고, 타입이 같은 빈이 여러개 있을 경우 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.

2-2) @Qualifier 어노테이션 사용 예시
- Qualifier는 추가 구분자를 붙여주는 방법
- 빈 등록 시 @Qualifier를 붙여준다. 
- 의존관계를 주입 시, @Qualifier를 붙여주고 등록한 이름을 적는다.
- 수정자 자동 주입일 경우 
- @Qualifier로 주입할 때 @Qualifier("rateDiscountPolicy)를 찾지 못할 경우, rateDiscountPolicy라는 이름의 스프링 빈을 추가로 찾게된다.
- @Qualifier는 @Qualifer를 찾는 용도로 명확하게 사용하는 것이 좋다.

2-3) @Primary 어노테이션 사용 예시 
- @Primary 어노테이션은 우선순위를 정해준다. @Autowired 시에 여러 빈이 매칭되면 @Primary가 우선권을 가짐

3) 우선 순위 
- @Primary보다는 @Qualifier의 우선 순위가 더 높다.

 

■ 어노테이션 직접 만들기

- @Qualifier("rateDiscountPolicy")를 사용하면 문자를 입력하는 것이기 때문에, 컴파일 시 타입 체크가 안된다.
- 즉 "rateDiscountPolicy"를 잘못 적어도 컴파일 오류는 발생하지 않지만, 의존관계 자동 주입 시 오류가 발생할 것이다.
- 어노테이션을 만들어 사용하면 문제를 해결할 수 있다.

- 추가 구분자 @Qualifier를 갖는 MainDiscountPolicy 어노테이션 생성
- rateDiscountPolicy 스프링 빈 생성 시, @MainDiscountPolicy 어노테이션을 생성하여 추가 구분자 값을 설정
- 의존관계 자동 주입 시, @MainDiscountPolicy를 사용 

[어노테이션]
- 어노테이션은 상속이라는 개념이 X
- 여러 어노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능
- @Qualifier뿐만 아니라 다른 어노테이션들도 조합해서 사용할 수 있다. 

 

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

해당 타입의 스프링 빈이 다 필요한 경우

[로직 분석]
- DiscountService 클래스가 스프링 빈으로 등록이 될 때, policyMap은 모든 DiscountPolicy 타입의 객체를 주입받게 된다.
- 이때 fixedDiscountPolicy, rateDiscountPolicy가 주입된다. 

- Map<String, DiscountPolicy> : map의 키에 스프링 빈의 이름을 넣어주고, 키에 대한 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.
- List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다. 
import com.example.demo.AutoAppConfig;
import com.example.demo.member.Grade;
import com.example.demo.member.Member;
import com.example.demo.order.DiscountPolicy;
import com.example.demo.order.OrderService;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

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

public class AllBeanTest {

    @Test
    @DisplayName("모든 빈을 사용해야하는 경우")
    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 price = discountService.disCount(member, 20000,"rateDiscountPolicy");

        Assertions.assertThat(price).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);

            System.out.println("discountPolicy = " + discountPolicy);
            System.out.println("discountCode = " + discountCode);

            return discountPolicy.discount(member, price);
        }
    }
}

 

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

1) 편리한 자동 기능을 기본으로 사용
- 컴포넌트 스캔과 자동 주입
- 스프링부트는 컴포넌트 스캔을 기본으로 사용
- 업무 로직은 숫자도 매우 많고, 개발을 시작하면 컨트롤러, 서비스, 리포지토리 등 어느정도 유사한 패턴이 있다. 이럴 경우 자동 기능을 적극 사용하는 것이 좋다.

2) 수동 빈 등록은 언제 사용하는 것이 좋을까?
- 설정 정보를 통해서 수동으로 빈을 등록하고 의존관계도 수동으로 주입
- 기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다. 이럴 경우 수동으로 빈을 등록하고 의존관계를 주입하는 것이 좋다.
- 비즈니스 로직 중에서 다형성을 적극 활용할 때도 수등으로 빈을 등록하고 의존관계를 주입하는 것을 고민해보자!! (상황에 맞게)

3) 업무 로직 빈 vs 기술 지원 빈 
- 업무 로직 빈 : 컨트롤러, 서비스, 리포지토리 등이 보통 업무 로직이다. 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
- 기술 지원 빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용, 데이터베이스 연결이나 공통 로그 처리처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술

 

[출처 : 인프런 스프링 핵심 원리 기본편]