🌈 [Section2] 19. DI (Dependency Injection) 2

📕 오늘 배운 내용!

• Java 기반 컨테이너(Container) 설정
• 컴포넌트 스캠 (Component Scan)
• 의존관계 주입 방법

---

✏️ Java 기반 컨테이너(Container) 설정

✔ 중요 애너테이션

✔️ @Configuration

• 설정파일의 클래스 레벨에서만 사용
  ( 우리가 생성할 객체 클래스 위에 작성 )

➜ "여기 내가 가지고 있는 Bean들이 있어 !!" 하고 알려주는 것

💡 설정파일
우리가 사용하는 빈들의 정보와 의존성 정보가 어떻게 이루어져 있는지 쓰여있는 파일

• 클래스 레벨에서만 사용
  
  

✔️ @Bean

• 설정파일 내의 메서드 레벨에서만 사용
  ( 객체 클래스 내부의 생성자(메서드) 위에 작성 )
  ➜ 메서드가 Spring 컨테이너에서 관리할 새 객체를 인스턴스화, 구성 및 초기화한다는 것을 나타내는 데 사용

➜ 스프링 컨테이너한테 "얘네가 사용할 Bean들이야 !!" 하고 알려주는 것

//인스턴스화 할 때
@Configuration //클래스명에 이걸 쓰고
public class DependencyConfig {
    @Bean //해당 클래스 내의 메서드명에는 이거 씀
    public MyService myService() {
        return new MyServiceImpl();
    }
}

💡 XML 설정 방식

<beans>
    <bean id="myService" class="com.acme.services.MyServiceImpl"/>
</beans>

 

✔ AnnotationConfigApplicationContext 사용하여 스프링 컨테이너를 인스턴스화

(애너테이션을 이용해 Config 클래스 설정하는 방법)

• ApplicationContext 구현 방법
  ➜ 아래와 같은 애너테이션이 달린 클래스를 파라미터로 전달 받음

1. ✔️ @Configuration 클래스
➜ 클래스 위에 @Configuration가 입력되면, 이 애너테이션이 붙은 그 클래스 자체가 BeanDefinition으로 등록되고,
클래스 내에서 선언된 모든 @Bean이 붙은 메서드들도 Bean 정의로 등록됨
( @Configuration 애너테이션도 ctrl+B 해서 보면, @Configuate 애터테이션이 달려있어 그 객체 또한 Bean으로 자동 정의됨 )

Ex.

public static void main(String[] args) {
    ApplicationContext a = new AnnotationConfigApplicationContext(DependencyConfig.class);
    ToDo todo = a.getBean(Todo.class);
    todo.doStuff();
}

➜위 예시에서는 @Configuration 클래스(DependencyConfig.class)를 파라미터에 입력함으로써 사용하고 있음

2. ✔️ @Component 클래스

3. ✔️ JSR-330 메타데이터

➜ @Component가 붙은 클래스와 JSR-330 클래스가 제공되면 BeanDefinition으로 등록됨
( 필요한 경우 해당 클래스 내에서 @Autowired/@Inject와 같은 DI 메타데이터가 사용되는 것으로 가정 )

Ex.

public static void main(String[] args) {
    ApplicationContext a = new AnnotationConfigApplicationContext(ToDoImpl.class, Dependency1.class, Dependency2.class);
    ToDo todo = a.getBean(ToDo.class);
    todo.doStuff();
}

➜ @Component/JSR-330 주석이 달린 클래스는 생성자에 입력으로 사용
( ToDoImpl/Dependency1/Dependency2에 스프링 의존성 주입 애너테이션 @Autowired를 사용함 )

 

✔ @Bean 애너테이션 사용하기

[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-java-bean-annotation

✔️ @Bean

• 메소드 레벨 애너테이션 ( 메서드에 붙이는 애너테이션 )
• XML의 에서 제공하는 일부 속성을 지원
  ( @Bean이 XML의 의 직접적인 유사체라서 )

- init-method
[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-factory-lifecycle-initializingbean
⠀
- destroy-method
[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-factory-lifecycle-disposablebean

- autowiring
[참고] https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#beans-factory-autowire⠀

- name.

• @Configuration-annoted / @Component-annoted 클래스에서 사용 가능
  ( @Configuration/@Component 가 붙은 클래스 내에서 사용 가능 )
• @Bean을 직접 정의하는 것도 가능
  ( But, 이는 가시성을 제한함 ⬇️ )
  
   

💡 XML 사용 방식

<beans>
    <bean id="transferService" class="com.acme.TransferServiceImpl"/>
</beans>

➜ 애너테이션 사용 방식과 XML 방식 모두 ApplicationContext 내에서 transferService를 사용 가능하게 함

✔️ 기본 메서드 사용하여 빈 정의하는 방식
➜ 기본 메서드에서 빈(Bean) 정의가 있는 인터페이스를 구현하여 Bean configuration 설정 가능

public interface BaseConfig {
    @Bean
    default TransferServiceImpl transferService() {
        return new TransferServiceImpl();
    }
}
@Configuration
public class DependencyConfig implements BaseConfig { //여기서 인터페이스 구현
}

 

✔ Bean 의존성

@Bean-annotated 메서드는 해당 bean을 구축하는데 필요한 의존성을 설명하는 매개 변수를 가질 수 있음
➜ 이 파라미터로 의존성을 구체화시킬 수 있음

@Configuration
public class DependencyConfig {

    @Bean
    public TransferService transferService(AccountRepository accountRepository) {
    // 이 부분에서 매개변수 사용 중
        return new TransferServiceImpl(accountRepository);
    }
}

 

✔ @Configuration 애너테이션 사용하기

@Configuration

• 해당 객체가 bean definitions의 소스임을 나타내는 애너테이션
• @Bean-annoted 메서드를 통해 bean을 선언
• 이 @Configuration-annoted 클래스의 @Bean 메서드에 대한 호출을 사용하여 bean 사이의 의존성을 정의할 수도 있음
  
  

✔️ Bean 간 의존성 주입

• 생성자 주입을 통해 참조
  ( But, 이 방식은 @Bean-annoted 메서드가 @Configuration 클래스 내에 선언된 경우에만 작동 )
  ( @Component 클래스에는 사용 불가 )

Ex.

@Configuration
public class AppConfig {
    @Bean
    public BeanOne beanOne() {
        return new BeanOne(beanTwo()); //아래서 정의한 bean을 주입
    }
    @Bean
    public BeanTwo beanTwo() {
        return new BeanTwo();
    }
}

➜ beanOne은 생성자 주입을 통해 beenTwo에 대한 참조를 받음

---

✏️ Java 기반 설정 환경에서 내부적으로 작동하는 방식

@Configuration
public class DependencyConfig {

    @Bean
    public MemberService memberService1() {
        MemberServiceImpl memberService = new MemberServiceImpl();
        memberService.setMemberHyunju(memberHyunju()); //여기 1
        return memberService;
    }

    @Bean
    public MemberService memberService2() {
        MemberServiceImpl memberService = new MemberServiceImpl();
        memberService.setMemberHyunju(memberHyunju()); //여기 2
        return memberService;
    }

    @Bean
    public MemberHyunju memberHyunju() {
        return new MemberHyunjuImpl();
    }
}

위 예시에서, memberHyunju()가 memberService1()와 memberService2() 에서 각각 한번씩 호출되어 2번 불리고 있음

이 메서드는 MemberHyunjuImpl의 새 인스턴스를 만들고 이를 반환하므로, 일반적으로 두 개의 인스턴스(각 서비스마다 하나씩)가 있어야 함

But, 여기서 문제가 있음

Spring에 인스턴스화된 빈은 기본적으로 싱글톤 범위를 가져 한번만 사용되어야 하는데,
위 예시는 한 객체가 두 곳에서 불리고 있음

모든 @Configuration들은 시작하자마자 CGLIB를 사용하여 하위분류 됨

그 하위 클래스에서 자식 메서드는 부모 메서드를 호출하고 새 인스턴스를 생성하기 전에, 먼저 컨테이너에 캐시된(범위 지정된) bean들이 있는지 확인함

💡 CGLIB (Code Generator Libray)
- 클래스의 바이트 코드를 조작하여 프록시 객체를 생성해 주는 라이브러리

---

💡 프록시 객체 (Proxy)
- 특정 객체를 감싸 프로퍼티 읽기, 쓰기와 같은 객체에 가해지는 작업을 중간에서 가로채는 객체

 

✔ 애너테이션을 사용해 스프링 컨테이너를 구성하는 방법

@Import

• 구성을 모듈화하는데 사용
  ( like. XML 파일 내에서 요소가 사용되는 것 )
• 다른 구성 클래스(configuration 클래스)에서 @Bean definitions를 가져올 수 있게 함
• @Configuration public class ConfigA { @Bean public A a() { return new A(); } }

@Configuration
public class ConfigA {

    @Bean
    public A a() {
        return new A();
    }
}

@Configuration
@Import(ConfigA.class) //여기
public class ConfigB {

    @Bean
    public B b() {
        return new B();
    }
}

➜ 위와 같이 컨텍스트를 인스턴트화할 때 ConfigA.class와 ConfigB.class를 둘 다 지정하여 구체화할 필요없이, 아래와 같이 ConfigB만 제공하여 구체화 하면 됨

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(ConfigB.class);

    // now both beans A and B will be available...
    A a = ctx.getBean(A.class);
    B b = ctx.getBean(B.class);
}

➜ ctx에 Import(ConfigA.class) 받은 ConfigB.class 사용으로 인해 ctx.getBean(A.class)가 가능해짐

➜ 컨테이너 인스턴트화를 단순화할 수 있음
( @Configuration이 접근 방식 생성하는 동안 하나의 클래스만 처리하면 되기 때문에 )

 

✔️ Imported @Bean Definitions에 의존성 주입의 문제점

• 실제로 사용될 때, 빈은 1개의 구성파일만 @Import 받지 않고, 여러 구성 클래스간에 걸쳐 서로 의존성 가짐

XML을 사용할 때는 컴파일러가 관여하지 않아 컨테이너 초기화 중에 ref=”some Bean”을 선언하여 스프링으로 해결할 수 있어 문제가 되지 않음

• @Configuration 클래스를 사용할 때, 자바 컴파일러는 구성 모델에 제약을 두고, 다른 빈에 대한 참조는 유효한 자바 구문이어야 함

 

💡 이의 해결방법

1. @Bean 메서드에 빈 의존성을 설명하는 임의의 개수의 파라미터넣기
2. @Autowired / @Value 주입 또는 다른 bean과 동일한 기능을 사용하기
( 단, @Configuration의 생성자 주입은 스프링 프레임워크 4.3에서만 지원 )
( 대상 빈이 하나의 생성자만 정의하는 경우 @Autowired 지정할 필요가 없음 (하나만 있으니까 자동으로 지정됨))

---

✏️ 의존관계 호출 순서 예시

➜ 워드로 작성해 놓은 것 참고 !!

---

✏️ Component Scan

• Bean으로 등록될 준비가 된 클래스들을 스캔하여, 스프링 빈으로 자동 등록해주는 것
  ( 지금까지는 자바 코드의 @Bean or XML의 등의 설정 정보에 등록할 스프링 빈들을 직접 작성하고 의존 관계도 명시했었음 )
  ➜ @Controller, @Service, @Component, @Repository 애노테이션을 붙인 클래스들이 빈으로 등록 될 준비를 한 것

Component Scan은 기본적으로 @Component 애노테이션을 빈 등록 대상으로 포함함

✔️ 그렇다면 @Controller / @Service 는 어떻게 인식할까?
➜ 이 두 애너테이션도 ctrl+B 하면 @Component 애너테이션이 붙어있기 때문에 자동으로 포함된다 !

💡 DependencyConfig와 비교한다면, 얘는 @Bean으로 등록한 클래스가 없음

• @ComponentScan 애너테이션은 애플리케이션이 맨 처음 생성될 때 자동으로 붙어있기 때문에 따로 쓰지 않아도 됨

✔️ @Configuration이 붙은 설정 파일도 스프링 빈으로 자동 등록됨
➜ @Configuration을 ctrl + B 해보면, 이 애너테이션 자체에 @Component 애너테이션이 붙어있기 때문 !

• basePackage를 설정해야함
  
  
• @Autowired 애너테이션으로 어디에 의존관계를 주입할지 정하면 의존관계 또한 자동으로 입력해줌
  ( @ComponentScan & @Component만 사용했을 때에, 의존성 관리하는 DependencyConfig 클래스에 어떤 의존 객체를 주입할지 명시해주지 않기 때문에 @Autowired 꼭 붙여주기 )

✔️ DependencyConfig 등의 @Configuration 설정이 된 파일이 있을 시 아래 코드 추가하여 ComponentScan의 Fliter 사용 가능
@ComponentScan(excludeFilters = @Filter(type = FilterType.ANNOTATION, classes = Configuration.class))

 

✔ Component Scan 사용 방법

1. Java 파일 안에서 설정하는 방법

@Configuration
@ComponentScan(basePackages = "com.rcod.lifelog")
public class ApplicationConfig {
}

➜ @Configuration - 이 클래스가 XML을 대체한는 설정 파일임을 알려주어 해당 클래스를 설정파일로 설정

➜ @ComponentScan - basePackages 설정해줌
( 이를 사용하지 않으면, 빈으로 설정할 클래스들을 직접 XML 파일에 일일이 등록해주어야 함 )

✔️ basePackages

• 탐색할 패키지의 시작 위치를 지정하고, 해당 패키지부터 하위 패키지 모두 탐색함
• @ComponentScan()의 매개변수로 basePackages = “”를 줄 수 있음

지정하지 않으면, @ComponentScan이 붙은 설정 정보 클래스의 패키지가 시작 위치가 됨

• 설정 정보 클래스의 위치를 프로젝트 최상단에 두고 패키지 위치는 지정하지 않는 방법이 가장 편할 수 있음
  ( 스프링 부트를 사용하면 @SpringBootApplication 를 이 프로젝트 시작 루트 위치에 두는 것을 추천 )
• @SpringBootApplication에 @ComponentScan이 들어있음

 

2. XML 방식의 Component Scan

<beans>
    <context:component-scan base-package="com.acme"/>
</beans>

 

✔ Component Scan 기본 대상

• @Component
  ➜ 컴포넌트 스캔에서 사용
  
  
• @Controller / @RestController
  ➜ 스프링 MVC 및 REST 전용 컨트롤러에서 사용
  
  
• @Service
  ➜ 스프링 비즈니스 로직에서 사용
  ➜ 특별한 처리를 하지 않음
  ➜ 개발자들이 핵심 비즈니스 로직이 여기에 있다는 비즈니스 계층을 인식하는데 도움이 됨
  
  
• @Repository
  ➜ 스프링 데이터 접근 계층에서 사용
  ➜ 스프링 데이터 접근 계층으로 인식하고, 데이터 계층의 예외를 스프링 예외로 변환
  
  
• @Configuration
  ➜ 스프링 설정 정보에서 사용
  ➜ 스프링 설정 정보로 인식하고, 스프링 빈이 싱글톤을 유지하도록 추가 처리 함
  ( ctrl + B 해보면, 해당 클래스의 소스 코드에는 @Component를 포함하고 있음 )

 

✔️ 필터

• includeFilters
  ➜ 컴포넌트 스캔 대상을 추가로 지정
  
  
• excludeFilters
  ➜ 컴포넌트 스캔에서 제외할 대상을 지정

✔️ FilterType 옵션

• ANNOTATION
  ➜ 기본값, 애너테이션으로 인식해서 동작
  
  
• ASSIGNABLE_TYPE
  ➜ 지정한 타입과 자식 타입을 인식해서 동작
  
  
• ASPECTJ
  ➜ AspectJ 패턴 사용
  
  
• REGEX
  ➜ 정규 표현식을 나타냄
  
  
• CUSTOM
  ➜ TypeFilter라는 인터페이스를 구현해서 처리

 

✔ Component Scan 동작 과정

1. ConfigurationClassParser 가 Configuration 클래스를 파싱
( @Configuration 어노테이션 클래스를 파싱하는 것 )

2. ComponentScan 설정을 파싱
( base-package 에 설정한 패키지를 기준으로
ComponentScanAnnotationParser가 스캔하기 위한 설정을 파싱 )

3. base-package 설정을 바탕으로 모든 클래스를 로딩

4. ClassLoader가 로딩한 클래스들을 BeanDefinition으로 정의
( 생성할 빈의 대한 정의를 하는 것 ).

5. 생성할 빈에 대한 정의를 토대로 빈을 생성

[참고] https://jess-m.tistory.com/m/14

---

✏️ 의존관계 주입 방법

1. 생성자 주입

• 생성자에 @Autowired를 하면 스프링 컨테이너에 @Component로 등록된 빈에서 생성자에 필요한 빈들을 주입

✔️ 특징
- 생성자 호출 시점에 딱 1번만 호출되는 것이 보장
( 생성자가 1개만 존재하는 경우에는 @Autowired를 생략해도 자동 주입 )
- 불변과 필수 의존 관계에 사용
- 생성과 동시에 바로 의존관계를 주입하기 때문에 NullPointerException 을 방지
- 주입받을 필드를 final로 선언 가능

✔️ 생성자가 1개일 때 @Autowired 없어도 작동되는 이유
- 스프링이 해당 클래스 객체를 생성하여 빈에 넣어야하는데, 생성할 때 생성자를 부를 수 밖에 없음 -> 빈을 등록함녀서 의존 관계도 자동으로 주입되는 것

 

2. 수정자 주입 (setter 주입)

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

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

 

✔️ 생성자 주입과의 차이점

• 생성자 대신 set필드명 메서드를 생성하여 의존 관계 주입
• 런타임 시점에 객체를 껴야하는 경우에 사용
  (But, 아주 드물어서 별로 사용 X)
• @Autowired를 입력하지 않으면 실행이 안됨
• 메서드를 public으로 열어두어 변경이 가능 ( 불변 X )
  
  

Ex.

@Component
public class CoffeeService {
  private final MemberRepository memberRepository;
  private final CoffeeRepository coffeeRepository;

  @Autowired
  public void setMemberRepository(MemberRepository memberRepository) { //set필드명
  //얘는 빈으로 등록되는 것이 아님 (@component를 달아야 빈이 됨)
  //얘는 그냥 단순하게 컨테이너가 의존관계를 이어주는 역할만 함
    this.memberRepository = memberRepository;
  }

  @Autowired
  public void setCoffeeRepository(CoffeeRepository coffeeRepository) { //set필드명
    this.coffeeRepository = coffeeRepository;
  }
}

 

3. 필드 주입

• 필드에 @Autowired 붙여서 바로 주입하는 방법
  ( 요즘 아예 사용 X )

✔️ 특징
- 코드가 간결해서 예전에 많이 사용된 방식이지만, 외부에서 변경이 불가능하여 테스트하기 힘들다는 단점 존재
- DI 프레임워크가 없으면 아무것도 할 수 없음
- 실제 코드와 상관 없는 특정 테스트를 하고 싶을 때 사용할 수 있음
( But, 정상적으로 작동되게 하려면 결국 setter가 필요 -> 수정자 주입을 사용하는게 더 편리 )

💡 생성자가 1개일 때 @Autowired 없어도 작동되는 이유
- 스프링이 해당 클래스 객체를 생성하여 빈에 넣어야하는데, 생성할 때 생성자를 부를 수 밖에 없음 -> 빈을 등록하면서 의존 관계도 자동으로 주입되는 것

 

4. 일반 메서드 주입

• 일반 메서드를 사용해 주입하는 방법
  ( 요즘 아예 사용 X )

✔️ 특징
- 한번에 여러 필드를 주입 받을 수 있음
- 일반적으로 사용되지 않음

---

✏️ 옵션 처리

• 주입할 스프링 빈이 없을 때 동작해야 하는 경우에, 오류가 발생하지 않도록 대상이 없다는 것을 표현하기 위해 처리 하는 것
  
  

1. @Autowired만 사용할 때, required 옵션 기본값인 true가 사용되어 자동 주입 대상이 없으면 오류가 발생하는 경우
2. 스프링 빈을 옵셔널하게 해둔 상태에서 등록이 되지 않고, 기본 로직으로 동작하게 하는 경우
   
   

✔️ 자동 주입 대상 옵션 처리 방법

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

---

✏️ 생성자 주입 사용 이유

1. 불변

• 애플리케이션이 실행될 때 정해져서 종료 전까지 변경되지 않음
  ( 변경되어서도 안됨 )
  ➜ 객체를 생성할 때 최초 1번만 호출되고 그 이후에는 다시 호출되는 일이 없기 때문에 불변하게 설계 가능한 것

 

2. 누락

• 호출할 때, 의존 관게 주입이 누락되면 NPE(Null Point Exception) 발생
• 생성자 주입 사용하면, 주입 데이터 누락 시 컴파일 오류 발생
  
  

3. final 키워드 사용 가능

• 필드에 fainal 키워드 사용 가능
• 생성자에서 값이 설정되지 않으면 컴파일 시점에서 java: variable (데이터 이름) might not have been initialized라는 오류 확인 가능
  ( 생성자 주입 외 나머지 방식은 생성자 이후에 호출되는 형태이기에 final 키워드 사용 불가 )
  
  

4. 순환 참조

• 순환 참조 방지
• 필드 주입과 수정자 주입은 빈이 생성된 후에 참조하기 땜누에 애플리케이션이 어떠한 오류/경고 없이 구동됨
  ( 실제 코드 호출될 때까지 문제 알 수 없음 )
• 생성자를 통해 주입하게 되면 BeanCurrentlyInCreationException 발생
  
  

✔️ 생성자 주입 방식의 장점 요약

• 의존관계 설정이 되지 않으면 객체생성이 불가능
• 컴파일 타임에 인지가 가능
• NPE 에러 방지가 가능
• 의존성 주입이 필요한 필드를 final 로 선언 가능
• (스프링에서) 순환참조 감지가 가능
  ( 순환 참조 시 앱구동이 실패하게 됨 )
• 테스트 코드 작성 용이
• 수정자 주입이 필요한 경우가 있을 수 있지만 옵션이 필요할 때만 선택하면 됨

 

🌼 의존방식 변경 예시

➜ 워드로 작성해 놓은 것 참고 !

🌼 컴포넌트 스캔 예시

➜ 워드로 작성해 놓은 것 참고 !

🌼 BeanDefinition 예시

➜ 워드로 작성해 놓은 것 참고 !

---

🌈 느낀점

으악 아직까지는 너무 추상적이라 잘 이해가 안가는 부분이 여러군데 있다
뭔가 직접 해봐야 이해가 잘 될 것 같은데 몇몇 대표적인 부분만 이해가 가고 아직 상세한 부분들을 잘 모르겠어서 앞으로 실습 많이 하면서 자주 다시 들여다 봐야겠다ㅠㅠ

 

( 본 게시물은 2022/10/14에 작성한 글을 옮긴 글입니다. 원문은 요기에 있음! )

728x90