Spring Framework - 의존관계 자동 주입

다양한 의존관계 주입 방법

의존관계 주입은 아래와 같이 크게 4가지가 존재

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

생성자 주입

• 생성자를 통해 의존관계를 주입 받는 방법
• 생성자 호출시점에 딱 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 주입)

• 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) 로 지정

자바빈 프로퍼티, 자바에서는 과거로부터 필드의 값을 직접 변경하지 않고, setXxx, getXxx 라는 메서드를 통해 값을 읽거나 수정하는 규칙이 있는데 그것이 자바빈 프로퍼티 규약임

필드 주입

• 필드에 바로 주입하는 방법
• 외부에서 변경이 불가능 하기 때문에 테스트하기 어려움
• DI 프레임워크가 없다면 아무것도 할 수 없음
• 되도록이면 사용하지 않을것

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

일반 메서드 주입

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

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

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

의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈 이여야만 동작함

옵션 처리

주입할 스프링 빈이 없다고 하더라도 동작해야 할 때가 있음 그러나 @Autowired만 사용한다면 required 옵션의 기본값이 true로 되어 있어 자동 주입 대상이 없다면 오류가 발생

자동 주입 대상을 옵션으로 처리하는 방법은 아래와 같음

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

//호출 안됨
@Autowired(required = false)
public void setNoBean1(Member member) {
  System.out.println("setNoBean1 = " + member);
}

//null 호출
@Autowired
public void setNoBean2(@Nullable Member member) {
  System.out.println("setNoBean2 = " + member);
}

//Optional.empty 호출
@Autowired(required = false)
public void setNoBean3(Optional<Member> member) {
  System.out.println("setNoBean3 = " + member);
}

# setNoBean1 은 @Autowired(required=false) 이므로 아예 호출이 안됨 
setNoBean2 = null
setNoBean3 = Optional.empty

@Nullable, Optional은 스프링 전반에 걸쳐서 지원함. 예를 들어 생성자 자동 주입에서 특정 필드에만 사용하는 것도 가능

생성자 주입을 선택해라

과거에는 수정자 주입과 필드 주입을 많이 사용했지만 최근에는 스프링을 포함한 DI 프레임워크 대부분이 생성자 주입을 권장함 그 이유에 대해선 아래와 같음

불변

• 대부분의 의존관계 주입은 한번 일어나면 어플리케이션 종료시점까지 의존관계를 변경할 일이 없음
  • 오히려 대부분의 경우, 의존관계는 어플리케이션 종료 전까지 변하면 안됨(불변이여야 함)
• 수정자 주입을 사용하면 setXxx 메서드를 public으로 열어두어야 함
• 생성자 주입은 객체를 생성할떄 1번만 호출되므로 이후에는 호출될 일이 없음. 그러므로 불변으로 설계할 수 있음

누락

프레임워크 없이 순수 자바 코드를 단위 테스트 하는 경우에 다음과 같이 수정자 의존관계인 경우

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

    ...
}

아래와 같이 테스트를 수행하면 동작은 함

@Test
void createOrder() {
    OrderServiceImpl orderService = new OrderServiceImpl();
    orderService.createOrder(1L, "itemA", 10000);
}

그러나 테스트 수행 결과는 Null Point Exception이 발생하는데, memberRepository, discountPolicy 모두 의존관계 주입이 누락되었기 때문임.

생성자 주입을 사용하면 위와 같이 주입 데이터가 누락 되었을때는 컴파일 오류가 발생하여 바로 오류 확인이 가능함

final 키워드

생성자 주입을 사용하면 필드에 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;

        // discountPolicy 필드는 final 이므로 값 설정이 필수이지만 누락되어 컴파일 오류 발생
    }
}

수정자 주입을 포함한 다른 나머지 주입 방식은 모두 생성자 이후에 호출되므로 필드에 final 키워드를 사용할 수 없음. 오직 생성자 주입 방식만 final 키워드를 사용 할 수 있음

정리

• 기본적으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하면 됨
  • 생성자 주입과 수정자 주입을 동시에 사용할 수 있음(final 이 아닌 경우)
• 되도록이면 항상 생성자 주입을 선택하도록 하고 가끔 옵션이 필요할때 수정자 주입을 선택하면 됨
  • 필드 주입은 테스트와 같이 특정한 상황이 아니면 사용하지 않을 것

조회 빈이 2개 이상일때

@Autowired는 타입으로 조회를 함 그러므로 선책된 빈이 2개 이상일때 문제가 발생하게 됨

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

@Component
public class RateDiscountPolicy implements DiscountPolicy {}

@Autowired
private DiscountPolicy discountPolicy

위와 같이 fixDiscountPolicy, rateDiscountPolicy 두개의 후보가 존재하게 되므로 UniqueBeanDefinitionException 오류가 발생하게 됨

NoUniqueBeanDefinitionException: No qualifying bean of type 
'hello.core.discount.DiscountPolicy' available: expected single matching bean 
but found 2: fixDiscountPolicy,rateDiscountPolicy

위와 같은 상황일 떄 하위 타입(구현클래스)로 지정할 수도 있지만 하위 타입으로 지정하는 것은 DIP에 위배하고 유연성을 떨어지게 만듬 또한 이름만 다르고 똑같은 타입의 스프링 빈이 2개 이상 있을때는 해결되지 않음

@Autowired 필드 명, @Qualifier, @Primary

조회 대상 빈이 2개 이상일 떄 크게 아래와 같이 3가지 방법으로 해결이 가능함

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

@Autowired 필드 명 매칭

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

// 기존 코드
@Autowired
private DiscountPolicy discountPolicy

// 필드 명을 빈 이름으로 변경
@Autowired
private DiscountPolicy rateDiscountPolicy

필드 명 매칭은 먼저 타입 매칭을 시도하고 그 결과에 여러 빈이 있을때 추가로 동작하는 기능

@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를 동일하게 사용 가능

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

@Primary

@Primary는 우선순위를 정하는 방법 @Autowired 시에 여러 빈이 매칭된다면 @Primary가 우선권을 가지게 됨

// RateDiscountPolicy 가 FixDiscountPolicy 보다 우선권을 가지게 됨
@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 보다 @Qualifuer가 더 우선권이 높음

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

최근 추세에서는 점점 자동 등록을 사용하고 있음. 스프링은 @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞추어 일반적인 어플리케이션 로직을 자동으로 스캔 할 수 있도록 지원함. 추가적으로 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고 있으며 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록되어 지도록 설계되어 있음

수동 빈 등록이 사용되면 좋은 경우

어플리케이션은 크게 업무로직과 기술로직 두가지 로직으로 나누어 질수 있음

• 업무로직
  • 웹을 지원하는 컨트롤러, 핵식 비지니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지터리등이 모두 업무로직
  • 보통 비지니스 요구사항을 개발할떄 추가되거나 변경됨
  • 개발시 컨트롤러, 서비스, 리포지토리 처럼 유사한 패턴이 존재
  • 보통 문제가 발생하더라도 어느 부분이 문제인지 명확하게 나타남
  • 그러므로 자동 빈 등록 을 사용하여도 무방함
• 기술로직
  • 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용됨
  • 데이터베이스 연결, 공통 로그처리등 업무로직을 지원하기 위한 하부기술이나 공통 기술 임
  • 기술로직은 어플리케이션 전반에 걸쳐 광범위 하게 영향을 미치므로 문제 발생시 정확한 포인트를 찾기가 어려움
  • 이러한 광범위하게 사용되는 기술로직의 경우 가급적 수동 빈 등록을 사용하여 명확하게 드러내는 것이 좋음

추가적으로 비지니스로직중에서 다형성을 적극 활용하는 경우에는 수동 빈 등록을 사용하거나 특정 패키지에 같이 묶어두는것이 좋음. 그렇게 하면 어떠한 빈들이 주입되는지 바로 확인이 가능 하기 떄문에 유지보수의 이점이 있음

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

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외이고 반면에 내가 직접 기술지원객체를 스프링 빈으로 등록한다면 수동으로 등록하여 명확하게 드러내는 편이 좋음

정리

• 되도록이면 편리한 자동 기능을 사용하도록 함
• 직접 등록하는 기술 지원 객체는 수동 등록
• 다형성을 적극 활용하는 비지니스 로직은 별도의 패키지에 몰아 넣거나 수동 등록을 고민해보면 좋음

---

참고

• 스프링 핵심 원리 - 기본편(김영한)