❯ DI(Dependency Injection)
IoC 원칙 구현을 위해 사용하는 방법을 말한다.
이때까지는 코드에서 직접 new 키워드를 사용해 객체를 생성하고 주입하는 방법을 사용했는데,
이러한 과정을 스프링을 통해서 수행할 수 있다.
❯ 스프링 컨테이너(Spring Container)
스프링 컨테이너란, 애플리케이션 빈의 생명 주기를 관리하는 컴포넌트*이다.
* 컴포넌트(Component) : 프로그래밍에서 재사용 가능한 각각의 독립된 모듈.
Bean의 생성, 관리, 제거 등의 역할을 담당한다.
현재는 Spring Boot 를 사용하여 개발자가 설정 등은 직접 진행하지 않는 경우가 많다.
스프링 컨테이너는 서로 다른 빈은 연결해 애플리케이션의 빈을 연결하는 역할을 한다.
<스프링 컨테이너 생성 과정>
- 스프링 컨테이너는 Configuration Metadata를 사용한다.
Configuration Metadata(어떤 객체를 인스턴스화, 설정, 구성할 것인지에 대한 정보) - 스프링 컨테이너는 설정 클래스 정보를 사용해 스프링 빈을 등록한다.
- new AnnotationConfigApplicationContext(구성정보이름.class)로 스프링에 있는 @Bean 메서드를 등록한다.
<스프링 컨테이너의 종류>
- BeanFactory : 스프링 컨테이너의 최상위 인터페이스. 빈을 등록하고 생성하고 조회하는 등 빈 관리역할을 한다.
getBean() 메서드를 통해 빈을 인스턴스화하며, @Bean 이 붙은 메서드 명을 빈의 이름으로 사용해 빈을 등록한다. - ApplicationContext : BeanFactory의 기능을 상속받아 제공한다.
빈 관리 부분은 BeanFactory가 제공하고 그 외의 부가기능을 제공한다.
ex. MessageSource, EnvironmentCapable, ApplicationEventPublisher, ResourceLoader
❯ 빈(Bean)
스프링 컨테이너에 의해 관리되는 재사용 소프트웨어 컴포넌트이다.
빈은 인스턴스화된 자바 객체를 의미한다. 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.
@Bean이 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다.
각 빈은 클래스 등록정보, Getter/Setter 메서드를 포함한다.
위에서 언급한 Configuration Metadata 를 통해 생성된다.
<BeanDefinition>
Bean은 BeanDefinition(빈 설정 메타정보)을 통해 정의되고, 이에 따라 활용법이 달라진다.
Bean 하나에 1개의 메타 정보가 생성된다.
BeanDefinition 인터페이스는 속성에 따라 Bean을 어떻게 생성하고 관리할지 결정한다.
다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하게 된다.
❯ 빈 스코프(Bean Scope)
BeanDefinition을 만들때 해당 Bean의 의존성, 구성 값, 특정 Bean 정의에서 생성된 개체의 범위 등을 제어할 수 있다.
스프링에서는 6개의 범위를 지원하며 4개는 ApplicationContext 를 사용하는 경우에만 사용할 수 있다.
- singleton : 기본 설정. 각 스프링 컨테이너의 단일 객체 인스턴스에 대해 단일 bean definition 범위를 지정하는것.
해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 것을 의미한다. 단일 인스턴스는 싱글톤 빈의 캐시에 저장된다.
private 생성자를 사용해 외부에서 임의로 new 키워드로 해당 객체를 인스턴스화 할 수 없게한다.
스프링 컨테이너 시작과 함께 생성되며 컨테이너 종료시 소멸 메서드도 자동으로 실행된다.(제거) - prototype : 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 스코프. 매우 짧은 범위의 스코프
- request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프
- session : 웹 세션이 생성되고 종료될때까지 유지되는 스코프
- application : 웹의 서블릿 컨텍스와 같은 범위로 유지되는 스코프
- websocket : 단일 bean definition의 범위를 websocket의 라이프사이클까지 확장하는것. ApplicationContext 에서만 유효
❯ Singleton 패턴
<싱글톤 패턴의 문제점>
싱글톤 구현을 구현하기 위한 코드가 많음 -> 실제 실습 결과, static final을 통해 인스턴스화 하고 get 메서드를 통해 호출해야했다.
private를 사용하므로 유연성이 떨어지고 인스턴스를 지정해서 가져오기 때문에 테스트하기가 어려워진다.
또한 여러 스레드에서 싱글톤 객체를 공유해서 사용할 경우 값이 바뀌게되면 혼선이 올 수 있다. 가급적 읽기만 가능해야한다.
싱글톤 빈은 애플리케이션 구동시 생성되므로 빈이 많을수록 구동 시간이 증가할 수 있다.
<문제점 해결>
스프링 컨테이너를 통해 위 문제점들을 해결할 수 있다.
싱글톤 객체로 생성하고 관리하는 기능을 싱글톤 레지스트리라고 한다.
별도로 클래스를 작성하지 않고도 설정파일에서 @Bean, @Configuration을 사용해 적용할 수 있다.
스프링 프레임워크의 작동 원리, 구성요소 등에 대한 학습을 진행했다.
매일매일 비슷한 느낌을 받고있기는 하지만, 프로그래밍 학습은 무조건 직접 수행해보고 계속 시도해보는게 중요한것같다.
'부트캠프 개발일기 > Spring' 카테고리의 다른 글
39일차: Spring Framework(Advice, JoinPoint) (0) | 2023.04.07 |
---|---|
38일차: Spring Framework(AOP) (0) | 2023.04.07 |
37일차: Spring Container 실습 (0) | 2023.04.05 |
35일차: Architecture, Spring Boot (0) | 2023.04.03 |
34일차: Spring Framework (0) | 2023.04.02 |