[Spring] 의존관계 자동 주입

다양한 의존관계 주입

---

다양한 의존 관계 주입 방법

- 생성자 주입

: 생성자를 통해 의존 관계를 주입 받는 것으로, 생성자 호출 시점에 딱 한번만 호출 되는 것이 보장되는 것이 특징이다. 불변, 필수 의존관계에 사용한다.

- 수정자 주입(Setter 주입)

- 필드 주입

- 일반 메서드 주입

 

# 생성자 주입

@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;
    }
    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }

    // for test
    public MemberRepository getMemberRepository(){
        return memberRepository;
    }
}

위와 같이 이전에 구현했었다.

>> OrderServiceImpl 클래스에 @Component 애노테이션이 있으므로 컴포넌트 스캔을 진행하며, 스프링 컨테이너에 OrderService 클래스가 빈으로 등록이 된다. 등록이 될려면 생성자가 호출이 되어야 하고, 마침 생성자에는 @Autowired 애노테이션이 존재한다. 그러면 스프링 컨테이너에서 MemberRepository 와 DiscountPolicy 를 꺼내서 의존관계를 주입해준다. 이와 같은 방법이 생성자 주입으로 호출 시점에 단 한번만 호출되기 때문에, 불변/필수 의존 관계에 주로 사용된다. 값을 세팅한 다음에 더이상 바뀌는 것을 원하지 않는 경우에는 수정자 메서드(setter, getter)를 만들지 않는 것이 좋다.

  위 OrderServiceImple 에서 아래와 같이 final 로 설정한 것을 알 수 있다.

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

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

  그러면 memberRepository 와 discountPolicy 는 반드시 값이 존재해야 하며, 존재하지 않으면 위 코드에서 컴파일 오류가 발생하도록 예방한 것이다.

 

* 중요한 것은 생성자가 단 한개만 있으면 @Autowired 를 생략하여도 자동 주입이 된다.(스프링 빈에만 해당)

 

# 수정자 주입(Setter 주입)

- setter 필드의 값을 변경하는 수정자 메서드를 통해서 의존관계를 주입한다.

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

private MemberRepository memberRepository;
private DiscountPolicy discountPolicy;

@Autowired
public void setMemberRepository(MemberRepository memberRepository){
    System.out.println("memberRepository = " + memberRepository);
    this.memberRepository = memberRepository;
}
@Autowired
public void setDiscountPolicy(DiscountPolicy discountPolicy){
    System.out.println("discountPolicy = " + discountPolicy);
    this.discountPolicy = discountPolicy;
}

- 생성자 주입은 자바 스프링이 빈을 등록하기 위해 OrderService 객체를 생성할 때 생성자가 무조건 호출되므로, 빈에 등록이 될 때 의존관계가 주입되도록 한다.

- 수정자 주입은 빈 등록 시점이 아닌, 두 번째 단계(의존관계를 등록하는)에서 의존관계가 등록되도록 하는 것이다. 

- @Autowired 는 주입할 대상이 없으면 오류가 발생한다. 주입할 대상이 없어도 동작하게 하려면 @Autowired(required = false) 라고 하면 된다.

- 자바빈 프로퍼티, 자바에서는 필드의 값을 직접 변경하지 않고 setter, getter 메서드를 통해 값을 읽고, 변경하는 규칙을 만들었는데 이를 자바빈 프로퍼티 규약이라고 한다.

# 필드 주입

- 코드가 간결하지만 외부에서 변경이 불가능하기 때문에 테스트가 힘들다.(중요)

- DI 프레임워크가 없으면 아무것도 할 수 없다.

- 그냥 사용하지 말자. 😒

@Bean
OrderService orderService(MemberRepository memberRepository, DiscountPolicy discountPolicy){
	new OrderServiceImple(memberRepository, discountPolicy) // <----
}

(간혹 사용하는 경우)

- 애플리케이션의 실제 코드와 관계없는 테스트 코드를 작성할 시.

- 스프링 설정을 목적으로 하는 @Configuration 과 같은 곳에서 특별한 용도로 사용

 

 

# 일반 메서드 주입

- 일반 메서드를 통해서 주입받는다.

- 한 번에 여러 필드를 주입받을 수 있다.

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

(참고) 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야지만 동작하며, 스프링 빈이 아닌 Member 와 같은 클래스에서 @Autowired 코드를 적용한다고 할 지라도 아무런 동작을 수행하지 않는다.

 

# 옵션 처리

- 주입할 스프링 빈이 없는 경우에도 동작을 해야 하는 경우

- @Autowired 만 사용하면 required option 의 default 가 true 라서 자동주입대상이 없는 경우에는 오류가 발생한다.

- 이에 자동 주입 대상을옵션으로 처리하는 방법은 아래와 같다.

(1) @Autowired(required=false) : 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출이 안되도록 함

(2) org.springframework.lang.@Nullable : 자동주입할 대상이 없으면 null 이 입력됨

(3) Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력됨.

 

public class AutowiredTest {
    @Test
    void AutowiredOption(){
        ApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }
    static class TestBean{
        @Autowired(required = false)
        public void setNoBean1(Member noBean1){
            // 스프링이 관리하고 있지 않은 빈인 Member
            System.out.println("noBean1 = " + noBean1);
        }
        @Autowired
        public void setNoBean2(@Nullable Member noBean2){
            // 스프링이 관리하고 있지 않은 빈인 Member
            System.out.println("noBean2 = " + noBean2);
        }

        @Autowired
        public void setNoBean3(Optional<Member> noBean3){
            System.out.println("noBean3 = " + noBean3);
        }
    }

}

noBean2 = null
noBean3 = Optional.empty

- 위 테스트 코드에서 Member 는 스프링 빈이 아니다.

- setNoBean1() 의 경우 @Autowired 의 옵션이 (required=false) 이므로 해당 메서드의 호출 자체가 안된다.

 

# 생성자 주입을 사용해야 하는 이유

[불변성]

- 대부분의 의존관계는 한번 설정되면 애플리케이션 종료 시점까지 의존관계가 변경해야 할 이유가 없다. 변경되지 않아야 좋다.

- 수정자 주입을 사용하면 setter 을 public 으로 열어두어야 한다. 이는 누군가에 의해 의존관계가 변경될 수 있기 때문에 위험하다. 생성자 주입은 객체 생성 시 단 1번만 호출되기 때문에 불변하다.

 

[누락]

- 프레임워크 없이 순수한 자바 코드를 단위 테스트할 수 있다.

class OrderServiceImplTest {
    @Test
    void createOrder(){
        MemoryMemberRepository memberRepository = new MemoryMemberRepository();
        memberRepository.save(new Member(1L, "name", Grade.VIP));

        OrderServiceImpl orderService = new OrderServiceImpl(memberRepository,new FixDiscountPolicy());
        Order order = orderService.createOrder(1L, "itemA", 10000);
        Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
    }
}

[final 키워드의 사용 가능]

- 생성자 주입을 사용하면 필트에 final 키워드를 사용할 수 있다.

- final 키워드를 사용할 시, 초기값을 설정하지 않으면 생성자 시에만 값을 넣어주어야 하며, final 키워드를 사용했지만 값이 들어가지 않으면 컴파일 오류가 발생한다.

- 생성자에서 값이 설정되지 않더라도 컴파일 오류가 발생해서 안전하다.

(참고) 수정자 주입을 포함하여 나머지 주입 방식들은 모두 생성자 이후에 호출되기 때문에 필드에 final 키워드를 사용할 수 없고 생성자 주입 방식만 fianl 키워드를 사용할 수 있다.

 

[정리]

- 생성자 주입 방식은 프레임워크에 의존하지 않고 순수한 자바 언어의 특징을 잘 살리는 방법이다.

- 기본적으로 생성자 주입을 사용하는 것이 좋고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 된다. 이와 같이 생성자 주입과 수정자 주입을 동시에 사용할 수 있다.

- 항상 생성자 주입을 우선적으로 선택하는 것이 좋으며, 수정자 주입은 옵션으로 필요 시에 선택하도록 하자. 필드 주입은 사용하지 말자.

 

# 롬복과 최신 트렌드

- 개발을 진행하다 보면 대부분의 경우에 다 불변이고 이러한 경우에는필드에 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;
    }
 }

먼저, 생성자가 하나밖에 없으므로 @Autowired 를 생략할 수 있다.

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

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

- 그리고 이제 롬복 라이브러리를 적용해보자.

- 롬복 라이브러리를 사용하면 @RequiredArgsConstructor 을 통해서 fianl 이 붙은 필드들을 모두 모아서 생성자를 자동으로 만들어준다. 그러면 아래와 같이 간소화할 수 있다.

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

lombok 이 자바의 애노테이션 프로세서 기능을 사용하여 컴파일 시점에 생성자 코드를 자동으로 생성해준다. 😲

 

[정리]

최근에는 생성자를 단 하나만 만들고 @Autowired 를 생략하는 방법을 주로 사용하는데, Lombok 라이브러리의 @RequiredArgsConstructor 을 같이 사용하여 코드를 깔끔하게 구현할 수 있다.

 

# 조회 빈이 2개 이상인 경우 🤨

@Autowired 는 Type 으로 조회를 수행한다.

그러면 @Autowired private DiscountPolicy discountPolicy 라고 하면,

ac.getBean(DiscountPolicy.class) 와 같이 유사하게 동작한다.

그런데, Type 으로 빈을 조회하면 선택되는 빈이 2개 이상인 경우가 발생할 수 있고 이러한 경우에는 문제가 된다. DiscountPolicy 의 하위 타입인 FixDiscountPolicy, RateDiscountPolicy 가 둘 다 스프링 빈으로 선언되어 있을 때,

@Autowired private DiscountPolicy discountPolicy 와 같이 의존관계 자동 주입을 실행하면

 available: expected single matching bean but found 2: fixDiscountPolicy,rateDiscountPolicy

와 같은 NoUniqueBeanDefinitionException 오류가 발생한다. 사실, 하위타입으로 지정하여 해결할 수 있지만 이는 DIP 를 위배하고 프로그램의 유연성을 떨어뜨린다. 혹은 이름만 다르고 완전히 같은 타입의 스프링빈이 2개 있는 경우는 해결할 수 없을 것이다. 스프링 빈을 수동으로 등록해서 문제를 해결할 수 도 있겠지만, 외의 다양한 해결 방법이 있다. 

 

- @Autowired 필드 명 매칭

- @Qulifier → @Quilifier 끼리 매칭 → 빈 이름 매칭

- @Primary 사용

 

  @Autowired 필드 명 매칭

@Autowired 는 type 으로 매칭을 시도하는데, 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가적으로 매칭한다. (타입 매칭 시도를 먼저 하는데, 매칭 결과가 2개 이상이면 필드 명, 파라미터 명으로 빈 이름을 매칭한다.)

 

  @Qualifier 사용 (추가 구분자)

주입 시 추가적인 방법을 제공하는 것임. (빈 이름 변경이 아님!)

예를 들어, @Qualifier("mainDiscountPolicy") 라고 주입하려고 하는데 못찾는다면, mainDiscountPolicy 라는 이름의 스프링 빈을 추가적으로 탐색한다. 즉 @Qualifier 은 @Qualifier 끼리 매칭을 시도하고, 못찾는다면 빈 이름을 매칭하는데 여기서도 못찾으면 NoSuchBeanDefinitionException 예외를 발생시킨다. 

 

  @Primary 사용 (우선순위 정하기) 

@Autowired 수행 시 여러 개의 빈이 매칭되면 @Primary 가 우선권을 가진다. 

 

  Primary, Qualifier 의 활용

예를 들어 코드에서 메인으로 사용하는 데이터베이스가 있고, 서브 데이터베이스가 있다고 가정해보자. 메인 데이터베이스와의 커넥션을 얻는 스프링 빈은 @Primary 를 적용하여 @Qualifier 없이 디폴트처럼 조회할 수 있도록 하고, 서브 데이터베이스 커넥션 빈을 얻을 때는 @Qualifier 을 지정하여 명시적으로 얻는 방법으로 코드를 깔끔하게 작성할 수 있다. 스프링에서 기본적으로 자동보다는 수동이, 넓은 범위의 선택권보다는 좁은 범위의 선택권이 우선 순위가 높다. 그래서 이 경우에서도 마찬가지로 @Qualifier 가 우선권이 더 높다.

 

# 조회한 빈이 모두 다 필요한 경우

특정 타입의 스프링 빈이 다 필요한 경우에는 어떻게 대처할까?

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.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

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

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

public class AllBeanTest {
    @Test
    void findAllBean(){
        AnnotationConfigApplicationContext 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 rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");
        assertThat(rateDiscountPrice).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 에 따라서 map 에서 해당하는 스프링 빈을 찾아서 실행하는 것이다.

- Map<String, DiscountPolicy> 는 map 의 키에 스프링 빈의 이름을 넣어주고, 그 값으로 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

- List<DiscountPolicy> 는 DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다.

- 만약에 해당하는 타입의 스프링 빈이 없으면 빈 Collection 이나 Map 을 주입한다.

 

# 자동, 수동 의존관계 주입의 올바른 실무 운영 기준

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

- 직접 등록하는 기술 지원 객체는 수동으로 등록하자.

- 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민하자.

---

Reference

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8

스프링 핵심 원리 - 기본편 - 인프런 | 강의