[Spring] 핵심 원리 기본 (7) - 의존 관계 자동 주입

📌 다양한 의존관계 주입 방법

✅ 생성자 주입

@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를 생략해도 자동 주입됨
• 생성자 호출 시점에 딱 1번만 호출되는 것이 보장됨
• 불변, 필수 의존관계에 사용

 

✅ 수정자 주입

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

• setter를 통해서 의존관계를 주입하는 방법
• 선택, 변경 가능성이 있는 의존관계에 사용

 

✅ 필드 주입

public class OrderServiceImpl implements OrderService {

     @Autowired
     private MemberRepository memberRepository;
     @Autowired
     private DiscountPolicy discountPolicy;
}

• 필드에 바로 주입하는 방법
• 코드가 간결하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 단점이 있다.
• DI 프레임워크가 없으면 아무것도 할 수 없다.
• 애플리케이션의 실제 코드와 관계없는 테스트코드나 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용하자.

 

📌 옵션 처리

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

 

✅ 자동 주입 대상을 옵션으로 처리하기

//호출 자체가 안됨
@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);
}

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

 

📌 생성자 주입을 사용하자

✅ 불변

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

 

✅ 누락

• final 키워드를 사용하면 값을 선언과 동시에 할당해주어야 하는데 생성자에서 할당할 수 있다.
• final 변수에 값이 누락되면 컴파일 오류가 발생하기 때문에 의존 관계 주입의 누락을 쉽게 파악할 수 있다.

 

→ 기본적으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여하자. 필드 주입은 사용하지 않는 것이 좋다.

 

📌 롬복 라이브러리와 최신 트렌드

• 롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다.
• 최근에는 생성자를 딱 1개 두고, @Autowired를 생략하는 방법을 주로 사용한다. 여기에 Lombok 라이브러리의 @RequiredArgConstructor를 함께 사용하면 기능은 다 제공하면서 코드는 깔끔하게 사용할 수 있다.

 

롬복 라이브러리 추가

처음 프로젝트를 생성할 때 dependencies에서 추가해 줄 수도 있다.

configurations {
	compileOnly {
		extendsFrom annotationProcessor
	}
}

 dependencies {
 ...
	compileOnly 'org.projectlombok:lombok'
 	annotationProcessor 'org.projectlombok:lombok'

	testCompileOnly 'org.projectlombok:lombok'
	testAnnotationProcessor 'org.projectlombok:lombok'
 ...
 }

 

📌 조회 빈이 2개 이상일 때 문제

• @Autowired는 타입으로 조회한다. -> ac.getBean(DiscountPolicy.class)와 유사하게 동작
• 같은 타입의 클래스를 빈으로 등록(RateDiscountPolicy, FixDiscountPolicy)하고 상위 타입의 객체(DiscountPolicy)에 의존관계 주입을 실행하면 NoUniqueBeanDefinitionException이 발생한다.

 

✅ @Autowired 필드 명

@Autowired
private DiscountPolicy rateDiscountPolicy

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

 

✅ @Qualifier 사용

빈 등록

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

생성자 자동 주입 예시

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

• 추가 구분자를 붙여줄 수 있다. 빈의 이름을 바꾸는 것은 아님
• 만약 @Qualifier("mainDiscountPolicy")를 못찾으면 mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾음

 

✅ @Primary 사용

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}

@Component
public class FixDiscountPolicy implements DiscountPolicy {}

• 우선순위를 정하는 방법
• 여러 빈이 매칭되면 @Primary가 우선권을 가짐
• 사용 예> 메인 DB와 보조 DB가 있을 때, 메인DB에 @Primary를 걸어주는 방식으로 자주 사용됨

 

✅ @Primary vs @Qualifier

• @Qualifier는 모든 코드에 붙여주어야 해서 코드가 지저분해질 수 있다는 단점이 있다.
• 메인으로 사용될 빈은 @Primary를 사용해서 기본으로 조회하고 서브로 사용될 빈은 @Qualifier를 지정해서 필요할때만 명시적으로 획득하는 방식을 사용하면 코드를 깔끔하게 유지할 수 있다.
• 스프링은 자동보다 수동이, 넓은 범위의 선택권보다는 좁은 선택권이 우선순위가 높음
• @Qualifier > @Primary

 

📌 조회할 빈이 모두 필요할 때

의도적으로 해당 타입의 스프링 빈이 다 필요한 경우도 있다.

이 경우 주입받을 객체를 Map 또는 List로 설정하면 해당 타입의 모든 객체들이 주입된다.

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

 

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

• 편리한 자동 기능을 기본으로 사용
  • 스프링이 나오고 시간이 갈 수록 자동을 선호하는 추세이다.
  • 스프링은 @Component뿐만 아니라 @Controller, @Service, @Repository처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다.
  • 자동 빈 등록을 사용하면 설정 정보를 직접 작성하는 번거로운 작업이 줄어들고, 설정 정보를 관리할 필요가 없으며 OCP, DIP도 지킬 수 있다.
• 수동 빈 등록은?
  • 업무 로직 빈 : 컨트롤러, 서비스 리포지토리 등이 모두 업무 로직이며 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경됨
  • 기술 지원빈 : 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용
  • 업무 로직의 경우 개발 시 컨트롤러, 서비스, 리포지토리 처럼 어느정도 유사한 패턴이 있으므로 자동 기능을 적극 활용하는 것이 좋다.
  • 반면 기술 지원 로직은 수가 매우 적고, 광범위하게 영향을 미친다. 문제가 발생하게 되면 위치를 명확하게 파악하기 힘들므로 가급적 수동 빈 등록을 사용해서 명확하게 드러내는 것이 좋음
  • 또한 코드만 보고 어떤 객체가 빈으로 등록될지 알기 힘들때 패키지로 묶어놓거나 수동 빈 등록을 사용한다.

 

---

강의 링크

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