스프링 핵심5 - 의존관계 자동 주입

< 1. 다양한 의존관계 주입 방법 >

- 의존 관계 주입은 생성자 주입 / 수정자 주입(setter 주입) / 필드 주입 / 메서드 주입 4가지의 방법이 존재.

 

( 생성자 주입 )

- 생성자를 통해서 의존 관계를 주입 받는 방법

- 생성자 호출시점에 딱 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) 로 지정 )

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

class Data {
      private int age;
      public void setAge(int age) {
        this.age = age;
      }
      public int getAge() {
        return age;
	  }
}
// 자바빈 프로퍼티 규약 예시

 

 

( 필드 주입 )

- 코드가 간결하지만 외부에서 변경이 불가능해서 테스트 하기 힘들다는 치명적인 단점이 존재

- DI 프레임워크가 없으면 아무것도 할 수 없음 (사용 비추천)

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

// 애플리케이션의 실제 코드와 관계 없는 테스트 코드
// + 스프링 설정을 목적으로 하는 @Configuration 같은 곳에서만 특별한 용도로 사용

- @Bean 에서 파라미터에 의존관계는 자동 주입, 수동 등록시 자동 등록된 빈의 의존관계가 필요할 때 문제를 해결 가능

@Bean
    OrderService orderService(MemberRepository memberRepoisitory, DiscountPolicy
    discountPolicy) {
        new OrderServiceImpl(memberRepository, 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;
        }
}

 

 

- 의존관계 자동 주입은 스프링 컨테이너가 관리하는 스프링 빈이어야 동작 ( 스프링 빈이 아닌 Member 같은 클래스에서 @Autowired 코드를 적용해도 아무 기능도 동작하지 않음 )

 

 

 

< 2. 옵션 처리 >

- 주입할 스프링 빈이 없어도 동작해야 할 때가 있음

 

옵션을 통한 처리 방법

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

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

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

 

//Member는 스프링 빈이 아님
//호출 안됨
@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);
    }

 - @Nullable, Optional은 스프링 전반에 걸쳐서 지원 ( 생성자 자동 주입에서 특정 필드에만 사용해도 됨 )

 

 

 

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

( 이유1: 불변 )

- 대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없음. 오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안됨.(불변해야 한다.)

- 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 함

- 누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아님

- 생성자 주입은 객체를 생성할 때 딱 1번만 호출 -> 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있음.

 

( 이유2: 누락 )

- @Autowired 가 프레임워크 안에서 동작할 때는 의존관계가 없으면 오류가 발생하지만, 프레임워크 없이 순수한 자바 코드로만 단위 테스트를 수행하면 실행은 됨, but NPE(Null Point Exception)이 발생( 의존관계 주입이 누락되었기 때문 )

- 생성자 주입을 사용하면 주입 데이터를 누락 했을 때 컴파일 오류가 발생

- 생성자 주입을 사용하면 필드에 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 에 값을 설정해야 하는데, 이 부분이 누락
// java: variable discountPolicy might not have been initialized 오류 발생

- 컴파일 오류는 세상에서 가장 빠르고, 좋은 오류

- 수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출, 필드에 final 키워드를 사용할 수 없음( 오직 생성자 주입 방식만 final 키워드를 사용 )

 

- 생성자 주입 방식을 선택하는 이유는 여러가지가 있지만, 프레임워크에 의존하지 않고, 순수한 자바 언어의 특징을 잘 살리는 방법

- 기본으로 생성자 주입을 사용하고, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여(생성자 주입과 수정자 주입을 동시에 사용)

- 생성자 주입을 선택하고 가끔 옵션 필요시 수정자 주입을 선택, 필드 주입 비추천

 

 

< 3. 롬복(lombok) >

- 롬복 라이브러리의 환경을 build.gradle에 추가하고 사용 가능

- 롬복 라이브러리가 제공하는 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어줌

 

(최적화 전 코드)

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

// 생성자 한개라서 @Autowired 생략

(최적화 후 코드)

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

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

 

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

 

 

<  4. 조회 빈이 2개 이상일 때의 문제 >

 

- @Autowired 는 타입(Type)으로 조회

@Autowired
private DiscountPolicy discountPolicy // DiscountPolicy 타입으로 조회

- 타입으로 조회하기 때문에 "ac.getBean(DiscountPolicy.class)"와 유사하게 동작

 

- 스프링 빈 조회 게시글때와 마찬가지로 타입으로 조회하면 선택된 빈이 2개 이상일 때 문제가 발생

ex)

1. DiscountPolicy 의 하위 타입인 FixDiscountPolicy , RateDiscountPolicy 둘다 스프링 빈으로 선언

2. 의존관계 자동 주입을 실행

3. NoUniqueBeanDefinitionException 오류가 발생 (하나의 빈을 기대했지만 2개 발견됨)

 

- 하위 타입으로 지정할 수 도 있지만, 하위 타입으로 지정하는 것은 DIP(의존관계 역전 원칙)를 위배하고 유연성이 떨어짐

, 이름만 다르고, 완전히 똑같은 타입의 스프링 빈이 2개 있을 때도 해결이 안됨

 

 

조회 대상 빈이 2개 이상일 때 해결 방법

1. @Autowired 필드 명 매칭

2. @Qualifier -> @Qualifier끼리 매칭 -> 빈 이름 매칭

3. @Primary 사용

 

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

// 기존코드
@Autowired
private DiscountPolicy discountPolicy

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

- 필드 명이 rateDiscountPolicy 이므로 정상 주입

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

 

 

- 2. @Qualifier 는 추가 구분자를 붙여주는 방법

- 주입시 추가적인 방법을 제공하는 것이지 빈 이름을 변경하는 것은 아님

- 단점으로 주입 받을 때 다음과 같이 모든 코드에 @Qualifier 를 붙여주어야 함

// 예시1
@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

// 예시2
@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 로 주입할 때 @Qualifier("mainDiscountPolicy") 를 못찾으면 -> mainDiscountPolicy라는 이름의 스프링 빈을 추가로 찾음 ( 하지만 @Qualifier은 @Qualifier 를 찾는 용도로만 사용하는게 명확하고 좋음 )

 

- 직접 빈 등록시에도 @Qualifier를 동일하게 사용 가능

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

 

- NoSuchBeanDefinitionException 발생할 수 있다.

 

 

- 3. @Primary

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

// RateDiscountPolicy 가 우선권 가짐
@Component
  @Primary
  public class RateDiscountPolicy implements DiscountPolicy {}
  @Component
  public class FixDiscountPolicy implements DiscountPolicy {}

 

 

- Qualifier, Primary 활용과 관련하여

코드에서 자주 사용하는 메인 데이터베이스의 커넥션을 획득하는 스프링 빈이 있고, 코드에서 특별한 기능으로 가끔 사용하는 서브 데이터베이스의 커넥션을 획득하는 스프링 빈이 있다고 가정

->

데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary 를 적용해서 조회하는 곳에서 @Qualifier 지정 없이 편리하게 조회하고, 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier 를 지정해서 명시적으로 획득 하는 방식으로 사용하면 코드를 깔끔하게 유지 가능

 

 

- 스프링은 자동보다는 수동이, 넒은 범위의 선택권 보다는 좁은 범위의 선택권이 우선 순위가 높음. 즉 @Qualifier가 @Primary보다 우선권 높음

 

 

< 5. 애노테이션 생성하기 >

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
  ElementType.TYPE, ElementType.ANNOTATION_TYPE})
  @Retention(RetentionPolicy.RUNTIME)
  @Documented
  @Qualifier("mainDiscountPolicy")
  public @interface MainDiscountPolicy {
  }

 

@Component
  @MainDiscountPolicy
  public class RateDiscountPolicy implements DiscountPolicy {}

 

//생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
                          @MainDiscountPolicy DiscountPolicy discountPolicy) {
      this.memberRepository = memberRepository;
      this.discountPolicy = discountPolicy;
  }
  
//수정자 자동 주입
   @Autowired
  public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy
  discountPolicy) {
      this.discountPolicy = discountPolicy;
  }

- 애노테이션에는 상속이라는 개념이 없음

- 여러 애노테이션을 모아서 사용하는 기능은 스프링이 지원해주는 기능

 

 

< 6. 조회한 빈이 모두 필요할 때: 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, 10000,
"fixDiscountPolicy");
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        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("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
		} 
     }
}

(로직)

- DiscountService는 Map으로 모든 DiscountPolicy 를 주입받음 ( 이때 fixDiscountPolicy , rateDiscountPolicy 가 주입 )

- discount () 메서드는 discountCode로 "fixDiscountPolicy"가 넘어오면 map에서 fixDiscountPolicy 스프링 빈을 찾아서 실행

( “rateDiscountPolicy”가 넘어오면 rateDiscountPolicy 스프링 빈을 찾아서 실행 )

 

(주입)

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

- List<DiscountPolicy> : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아준다. 만약 해당하는 타입의 스프링 빈이 없으면, 빈 컬렉션이나 Map을 주입

 

 

- 스프링 컨테이너를 생성하면서 스프링 빈 등록: 스프링 컨테이너는 생성자에 클래스 정보를 받는다. 여기에 클래스 정보를 넘기면 해당 클래스가 스프링 빈으로 자동 등록

new AnnotationConfigApplicationContext(AutoAppConfig.class,DiscountService.class);

// new AnnotationConfigApplicationContext() 를 통해 스프링 컨테이너를 생성
// AutoAppConfig.class , DiscountService.class 를 파라미터로 넘기면서 해당 클래스를 자동으로 스프링 빈으로 등록
// 스프링 컨테이너를 생성하면서, 해당 컨테이너에 동시에 클래스들을 스프링 빈으로 자동 등록

 

( 자동 기능 사용하기!, 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있다. )

- 스프링은 @Component 뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원

- 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계

 

 

< 7. 업무 로직과 기술 지원 로직 >

- 빈과 관련해서

1. 업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직 ( 비즈니스 요구사항을 개발할 때 추가되거나 변경 )

2. 기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술

 

- 업무 로직은 숫자도 매우 많고, 한번 개발해야 하면 컨트롤러, 서비스, 리포지토리 처럼 어느정도 유사한 패턴이 있음 > 이런 경우 자동 기능을 적극 사용하는 것이 좋음 ( 문제가 발생해도 어떤 곳에서 문제가 발생했는지 명확하게 파악하기 쉽기 때문 )

- 기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 끼침, 업무 로직은 문제가 발생했을 때 어디가 문제인지 명확하게 잘 드러나지만, 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많음. 그래서 이런 기술 지원 로직들은 가급적 수동 빈 등록을 사용해서 명확하게 드러내는 것이 좋음

 

- 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해서 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋음

 

- 비즈니스 로직 중 다형성을 활용할 때:

의존관계 자동 주입 - 조회한 빈이 모두 필요할 때, List, Map 보기

예시로 DiscountService 가 의존관계 자동 주입으로 Map<String, DiscountPolicy> 에 주입을 받는 상황

여기에 어떤 빈들이 주입될 지, 각 빈들의 이름은 무엇일지 코드만 보고 한번에 쉽게 파악하기 어려움 >> 내가 개발했으니 크게 관계가 없지만, 만약 이 코드를 다른 개발자가 개발해서 나에게 준 것이라면 자동 등록을 사용하고 있기 때문에 파악하려면 여러 코드를 찾아봐야 함

(이 경우 수동 빈으로 등록하거나 또는 자동으로하면 특정 패키지에 같이 묶어두는게 좋음 )

// 위 예시를 수동 빈등록으로 변경
@Configuration
  public class DiscountPolicyConfig {
      @Bean
      public DiscountPolicy rateDiscountPolicy() {
          return new RateDiscountPolicy();
      }
      @Bean
      public DiscountPolicy fixDiscountPolicy() {
          return new FixDiscountPolicy();
      }
}

- 빈 자동 등록을 사용하고 싶으면 파악하기 좋게 DiscountPolicy 의 구현 빈들만 따로 모아서 특정 패키지에 모아두는 것이 좋음

(인프런 예제는 패키지에 나눠져 있음)