1. IOC란?
- IoC란 Inversion of Control의 줄임말이며, 제어의 역전이라고 한다.
- 스프링 애플리케이션에서는 객체(빈)의 생성과 의존 관계 설정, 사용, 제거 등의 작업을 개발자 대신 스프링 컨테이너가 담당한다.
- 이를 스프링 컨테이너가 코드 대신 오브젝트에 대한 제어권을 갖고 있다고 해서 IoC라고 부른다.
- 따라서, 스프링 컨테이너를 IoC 컨테이너라고도 부른다.
2. IoC 컨테이너란?
- 스프링에서는 IoC를 담당하는 컨테이너를 빈 팩토리, DI 컨테이너, 애플리케이션 컨텍스트라고 부른다.
- 스프링 컨테이너는 단순한 DI 작업보다 더 많은 일을 하는데, DI를 위한 빈 팩토리에 여러 가지 기능을 추가한 것을 애플리케이션 컨텍스트라고 한다.
- 정리하자면, 애플리케이션 컨텍스트는 그 자체로 IoC와 DI 그 이상의 기능을 가졌다고 보면 된다.
3. 빈 팩토리와 애플리케이션 컨텍스트
빈 팩토리와 애플리케이션 컨텍스트 관계를 살펴보면 아래와 같다.
3-1. 빈 팩토리
- 스프링 컨테이너의 최상위 인터페이스이다.
- 스프링 빈을 관리하고 조회하는 역할을 담당한다.
- 대표적으로 getBean() 메소드를 제공한다.
3-2. 애플리케이션 컨텍스트
애플리케이션 컨텍스트는 빈 팩토리 기능을 모두 상속 받아서 제공한다. 보통 애플리케이션 컨텍스트를 더 많이 사용한다. 따라서 우리가 IOC 컨테이너라고 하면 보통 이 애플리케이션 컨텍스트를 지칭한다.
- 애플리케이션 컨텍스트는 빈 팩토리에는 없는 기능을 포함하여 다음과 같은 기능을 추가로 제공한다(이 부분은 공부가 더 필요하다)
- 메시지 소스(인터페이스)를 활용한 국제화 기능
- 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력
- 환경 변수
- 로컬, 개발, 운영 등을 구분해서 처리
- 애플리케이션 이벤트
- 이벤트를 발행하고 구독하는 모델을 편리하게 지원
- 편리한 리소스 조회
- 파일, 클래스 패스, 외부 등에서 리소스를 편리하게 조회
- 메시지 소스(인터페이스)를 활용한 국제화 기능
4. 설정 메타 정보
IoC 컨테이너의 가장 기초적인 역할을 객체를 생성하고 이를 관리하는 것이다. 스프링 컨테이너가 관리하는 이런 객체는 빈이라 부른다. 설정 메타 정보는 바로 이 빈을 어떻게 만들고 어떻게 동작하게 할 것인가에 관한 정보이다.
스프링 컨테이너는 자바 코드, XML, Groovy 등 다양한 형식의 설정 정보를 받아들일 수 있도록 유연하게 설계되어 있다.
4-1. 애노테이션 기반 자바 코드 설정
- @Configuration : 1개 이상의 빈을 제공하는 클래스의 경우 반드시 명시해야 한다.
- @Bean : 클래스를 빈으로 등록할 때 사용한다.
4-2. XML 기반의 스프링 빈 설정
- XML 기반으로 설정하는 것은 최근에 잘 사용하지 않는다.
5. 스프링 빈 설정 메타 정보 - BeanDefinition
- 스프링은 어떻게 이런 다양한 형식을 지원하는 것일까? 그 중심에는 BeanDefinition이라는 추상화가 있다.
- 쉽게 말하자면, XML을 읽어서 BeanDefinition을 만들고, 자바 코드를 읽어서 BeanDefinition을 만든다. 따라서 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 되고 오직 BeanDefinition만 알면 된다.
- BeanDefinition을 빈 설정 메타 정보라 하는데, @Bean(어노테이션)과 <bean> (XML)당 각각 하나씩 메타 정보가 생성된다.
- AnnotationConfigApplicationContext는 AnnotatedBeanDefinitionReader를 사용해서 AppConfig.class를 읽고 BeanDefinition을 생성한다.
- GenericXmlApplicationContext는 XmlBeanDefinitionReader를 사용해서 appConfig.xml 설정 정보를 읽고 BeanDefinition을 생성한다.
- 새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition을 생성하면 된다.
6. DI란?
DI(Dependency Injection)란 스프링이 다른 프레임워크와 차별화되어 제공하는 의존 관계 주입 기능으로,
객체를 직접 생성하는 게 아니라 외부에서 생성한 후 주입 시켜주는 방식이다.
이처럼 그 의존 관계를 외부에서 결정하는 것을 DI(의존 관계 주입)라 한다.
스프링에서는 외부의 대상이 IoC 컨테이너가 되어, 빈을 알아서 주입해 준다.
DI(의존성 주입)를 통해서 모듈 간의 결합도가 낮아지고 유연성이 높아진다.
우리가 DI를 사용한다면 직접 만들고 관리하는 것이 아니라 사용만 하면 되기 때문에 약한 결합이 이뤄진다고 할 수 있다.
7. DI(의존 관계 주입) 구현 방법
7-1. 필드 주입
@Service
public class BurgerService {
@Autowired
private BurgerRecipe burgerRecipe;
}
변수 선언부에 @Autowired 어노테이션을 붙인다.
7-2. 수정자 주입
@Service
public class BurgerService {
private BurgerRecipe burgerRecipe;
@Autowired
public void setBurgerRecipe(BurgerRecipe burgerRecipe) {
this.burgerRecipe = burgerRecipe;
}
}setter를 사용한 주입이다.
7-3. 생성자 주입
@Service
public class BurgerService {
private BurgerRecipe burgerRecipe;
@Autowired
public BurgerRecipe(BurgerRecipe burgerRecipe) {
this.burgerRecipe = burgerRecipe;
}
}
생성자에 @Autowired 어노테이션을 붙여 의존성을 주입받을 수 있으며, 가장 권장되는 주입 방식이다. 만약 생성자가 하나라면 @Autowired 생략 가능하다.
7-4. 생성자 주입 방식이 권장되는 이유
- 수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 합니다.
즉 언제 어디서든 변경이 가능하다는 뜻입니다. - 또한 필드 주입으로 의존성 주입 시 final 키워드를 통한 선언이 불가능하고 객체가 변하기 쉬워진다.
- 문제는 우리가 주입하는 객체를 변경할 경우가 굉장이 드물고 기피해야한다. 왜냐하면 객체 생성 이후 내부가 변경이 가능하다면 우리가 의도하지 않은 부분에서 변화로 인해 예상과는 전혀 다른 결과(원하지 않는 객체의 주입 발생)가 발생할 수 있기 때문이다.
- 이런 수정자 주입방식과 필드 주입방식과는 다르게 생성자로 한번 의존 관계를 주입하면, 생성자는 다시 호출될 일이 없기 때문에 불변 객체를 보장한다. 또한 주입받는 객체가 생성되는 시점에 무조건 객체가 주입된다는 게 보장된다.
- 다른 방식들과는 다르게 생성자 주입 방식은 순환 참조 에러를 방지할 수 있다.
7-5. 순환 참조 에러방지
순환 참조 에러는 A객체가 B객체를 참조하고, B객체가 A객체를 서로 참조하고 있을 때 발생한다.
@Service
public class AService {
@Autowired
private BService bService;
public void hello() {
bService.hello(); //AService 객체가 BService 메서드 호출
}
}@Service
public class BService {
@Autowired
private AService aService;
public void hello() {
aService.hello(); //AService 객체가 BService 메서드 호출
}
}위 코드처럼 A 서비스의 hello() 메서드는 B객체를 참조하고, B 서비스의 hello() 메서드는 A객체를 참조한다.
애플리케이션을 실행하고, AService에서나, BService에서 hello() 메서드를 호출하면, 서로 메서드를 호출하다 결국 StackOverFlow에러(메모리 중 Stack영역에서)가 나서 애플리케이션이 다운되며 여기서 주목할 점은 이런 에러가 애플리케이션이 실행 중에 발생 한다는 점이다..
즉, 어플리케이션이 실행되고 있을 때, AService나 BService의 hello() 메서드가 호출되지 않으면 에러는 발생하지 않고, 개발자는 틀린 부분을 찾을 수가 없다.
정확히 말하자면, 순환 참조 에러가 아닌, 순환 참조에 의한 순환 호출 에러라고 할 수 있다.
이 에러는 수정자 주입으로 의존성을 주입해도 동일하게 발생한다.
반면에 생성자 주입 방식은 다르다.
@Service
public class AService {
private BService bService;
@Autowired
public AService(BService bService) {
this.bService = bService;
}
public void hello() {
bService.hello(); //AService가 BService 메서드 호출
}
}@Service
public class BService {
private AService aService;
@Autowired
public BService(AService aService) {
this.aService = aService;
}
public void hello() {
aService.hello(); //BService가 AService 메서드 호출
}
}이 애플리케이션을 실행하면, 실행이 되지 않고 순환 참조 문제가 있다며 예외가 발생하며,
이렇게 애플리케이션을 실행하기 전에 발생하는 컴파일 에러는 좋은 에러이다.
즉, 생성자 주입 방식을 사용하면 순환 참조 문제를 해결하는 것이 아니라, 순환 참조 문제를 애플리케이션 실행 시점에 알려줘서, 실제 서비스되기 전에 개발자로 하여금 순환 참조 문제를 해결할 수 있게 해 준다.
이러한 이유로 인해, Spring에서 객체 의존성 주입은 생성자 주입 방식을 사용하는 것이 권장된다.
8. 참고
https://steady-coding.tistory.com/600
'웹 > 스프링' 카테고리의 다른 글
| AOP란? 프록시 패턴이란? 스프링 AOP란? @Transactional 원리 (0) | 2022.06.03 |
|---|---|
| Spring MVC란? (0) | 2022.05.31 |
| RedisTemplate 사용해서 Redis 이용하기 (0) | 2022.04.18 |
| Spring Boot에서 통합 테스트코드 구현하기(JUnit5 + Mockito) (0) | 2022.04.17 |
| SQL이란? MVC란? (0) | 2022.02.06 |