[Spring] DI

📌 개인적인 공간으로 공부를 기록하고 복습하기 위해 사용하는 블로그입니다.
정확하지 않은 정보가 있을 수 있으니 참고바랍니다 :😸
[틀린 내용은 댓글로 남겨주시면 복받으실거에요]

Spring Framework 모듈 구성 - 아키텍처

• 청사진
• 기존에 틀만 있었다면 어떤 컨셉으로 서비스를 갖고 있는지 유추가능한 것.

시스템 아키텍처

• 인프라 아키텍처라고도 함
• 하드웨어와 소프트웨어를 모두 포함하는 어떤 시스템의 전체적인 구성을 큰 그림으로 표현한 것
• 컨셉만 볼 수 있도록 간단하게 무엇을 목적으로 인프라를 구축했는지 보고 알 수 있는 것

예제

1. 채팅서버를 구축하기 위한 전통적인 시스템 아키텍처

   - 문제점

   • 확장이 불가능
   • 사용자가 많아진다면 위 같은 아키텍처에는 문제가 발생

2. 개선한 아키텍처

   - 아키텍처 사용자의 요청을 분산시켜 주는 로드 밸런서 영역을 두어서 웹소켓 서버를 안정적으로 운영 - 로드밸런서가 로드가 덜되는 곳에 보내줌. - 여러 대의 웹소켓 서버로 확장이 가능하기 때문에 사용자의 요청이 늘어나더라도 서버의 부하를 줄일 수 있으며, 특정 서버에 장애가 발생하더라도 전체 시스템이 죽는 경우를 방지가능

   • 1번 서버가 부하가 걸려서 죽어도 다른데 보내면 됨 - 메시지 브로커 영역을 두어서 웹소켓 서버가 다중 서버로 구성이 되어 있더라도 특정 사용자들 간에 메시지를 주고받을 수 있는 공유 채널을 사용하는 것이 가능해짐.
   • 메세지브로커 - 상황을 공유할 수 있게 실시간 소통이 가능하게 해줌.

3. 전송속도 향상을 위해 개선된 아키텍처

   

   • mongoDB -> 비관계성 DB
   • 사용자의 요청과 서버의 응답이 이루어지는 전체 영역에 걸쳐서 Blocking 되는 요소가 없도록 리액티브 시스템을 구성하여 클라이언트의 요청을 보다 빠르게 처리가능
   • 웹소켓이 하나의 Connection과 연결되는 것에 반해 RSocket은 하나의 Connection 내에서 다중 요청 처리가 가능하기 때문에 대량의 요청을 안정적으로 처리가

소프트웨어 아키텍처

대표 사례 : Java 플랫폼 아키텍처

​

1. 애플리케이션
   1. 소프트웨어 종류의 하나로써 좁게는 데스크톱이나 스마트폰에서 사용하는 응용 프로그램을 말함
   2. 넓게는 클라이언트의 요청을 처리하는 서버 애플리케이션을 의미

2. 웹 애플리케이션을 위한 아키텍처 ⇒ 이것을 명확하게 잘 지키고 있는 것이 MVC

   

   웹 애플리케이션을 계층형으로 표현한 아키텍처 - 계층형 아키텍처(N-티어)

• API 계층(API Layer)은 클라이언트의 요청을 받아들이는 계층
  • 일반적으로 표현 계층(Presentation Layer)이라고도 불리고
  • REST API를 제공하는 애플리케이션의 경우 API 계층이라고 표현
• 서비스계층(Service Layer) = 비즈니스 계층은 API 계층에서 전달받은 요청을 업무 도메인의 요구 사항에 맞게 비즈니스적으로 처리하는 계층이다.
• 데이터 액세스 계층(Data Access Layer)은 비즈니스 계층에서 처리된 데이터를 데이터베이스 등의 데이터 저장소에 저장하기 위한 계층

• 위 계층을 아래처럼 구현 가능.

    @Controller, Rest
      
    Class User Controller{
      
    }
      
    @SERVICE
      
    Class UserService{
      
    }
      
    @Repository
      
    Class UserRepository{
    }
  

  • MVC를 빼고 개발하는 경우는 없음. (웹플럭스(=비동기 Framework)사용할 때 빼고) 앞으로 이런 구조를 철저하게 따라야 함.
  • controller만 구현하면 client와 데이터 주고받을 수 있음. = 정상적 app은 아님

아키텍처로 보는 Spring Framework 모듈(Module) 구성

• Spring Framework의 모듈 아키텍처를 통해 Spring이 어떤 기능들을 지원하는지 알 수 있음

​

모듈(Module)이란? Java에서는 일반적으로, 지원되는 여러 가지 기능들을 목적에 맞게 그룹화하여 묶어 놓은 것

이러한 모듈들은 Java의 패키지 단위로 묶여 있으며, 이 패키지 안에는 관련 기능을 제공하기 위한 클래스들이 포함되어 있음.

일반적으로 모듈은 재사용 가능하도록 라이브러리 형태로 제공되는 경우가 많음.

DI

DI(Dependency Injection) -코드로 이해하기

DI 방법 -3가지

1. 생성자
   1. 생성자를 통해 객체의 참조값이 주입 - 공식문서에서 권장하는 방법

   Dependency Injection :: Spring Framework

2. Setter 메서드를 통한 주입
3. 필드에 직접 주입 - 공식문서에서도 사라짐

예제

1. kiosk 클래스

    public class KioskApplication implements CommandLineRunner {    
        private Kiosk kiosk;
    		@Autowired
        public KioskApplication(Kiosk kiosk) {
            this.kiosk = kiosk;
        }
    }
   

2. kioskApplication 클래스

    public class Kiosk {
        private MenuItem[] menuItemArray;
        private Printer printer;
        private DiscountPolicy discountPolicy;
       
        @Autowired
        public Kiosk(MenuItem[] menuItemArray, Printer printer, DiscountPolicy discountPolicy) {
            this.menuItemArray = menuItemArray;
            this.printer = printer;
            this.discountPolicy = discountPolicy;
        }
   

3. 1번과 2번의 공통점
   1. 외부로부터 특정한 객체를 주입 받아 this 키워드를 사용하여 내부필드에 할당하여 값을 사용
   2. 모두 생성자를 통해 객체를 주입받음(DI)
      • KioskApplication : kiosk에 의존
      • kiosk : MenuItem, Printer, discountPolicy에 의존
4. 접근제어자 private
   1. 캡슐화 → 내부에서 사용되는 데이터들이 개발자의 실수 또는 어떤 원인을 통해 임의로 변경되지 않도록 보호하고 외부로의 노출을 방지하기 위한 것

5. private final

   

   1. final

      • 레퍼런스 타입일 때 주소 값 변경 불가능해짐 ⇒ 값을 더이상 못바꿈, 요소에는 접근 및 변경 가능

        

      • 생성자 주석처리 했을 때 빨간 줄 뜨는 이유 = 초기화가 되지 않았기 때문 ⇒ 무조건 초기화가 되어야 함.
      • final 이 붙고 생성자를 만들면 NPA를 방지할 수 있음
      • 초기화를 통해 Null 값이 들어올 일이 안 생기게 하기 위해 ⇒ NPA를 피하기 위한 가장 기본적인 패턴

6. AppConfig 클래스 ⇒ DI를 통해 변경과 확장에 유연한 코드를 설계

    @Bean
    public DiscountPolicy discountPolicy() {
        return new FixedAmountDiscountPolicy(100); 
        // 할인 금액을 여기서 설정
    }
   

   • DiscountPolicy 클래스의 생성자는 객체가 최초에 생성될 때, 각각 정률 할인(FixedRateDiscountPolicy)과 정액 할인(FixedAmountDiscountPolicy)이 적용될 수 있도록 객체들 간 의존 관계를 구성하는 역할을 수행

   • 할인 정책을 변경하고 싶을 때 return값의 객체만 변경해주면 됨.

       @Configuration
       public class AppConfig {
           @Bean
           public DiscountPolicy discountPolicy() {
               return new **FixedRateDiscountPolicy(20);**
           }
             
           --- 생략 ---
       }
     

7. @bean, @configuration
   1. @Bean 은 스프링 컨테이너에서 관리할 빈을 정의
   2. @Configuration객체가 Bean 정의의 소스임을 나타내는 클래스 수준 주석, 스프링 컨테이너가 관리할 빈을 정의하는 클래스임을 명시하는 데 사용됨

   3. 만약 discountPolicy가 2개가 있는데

       @Bean
       public DiscountPolicy discountPolicy(){
       	return new FixedAmountDiscountPolicy(100); 
       			//1. 할인금액을 여기서 설정
       }
       @Bean
       public DiscountPolicy discountPolicy2(){
       	return new FixedRateDiscountPolicy(0.2);
       	// 2. 할인률을 여기서 설정
       }
      

      아래 키오스크를 실행하게 되면 둘 중에 어떤 할인 정책이 반환될까?

      ​

      • 1번 할인금액을 설정한 FixedAmountDiscountPolicy가 반환됨
      • 이유는 @bean은 스프링 컨테이너에 넣을 때 반환하는 객체의 메서드 이름으로 들어가게 되고 호출할 경우 객체의 이름 먼저 확인 후 변수명 확인 ⇒ 똑같은 이름을 가진 할인금액으로 설정해준 메서드가 반영됨.

스프링 컨테이너와 빈

빈; 스프링 컨테이너가 관리하는 자바 객체를 스프링 빈(Bean), 스프링 컨테이너는 메타 정보를 기반으로 스프링 빈 생성 함.

스프링 컨테이너의 생성

ApplicationContext 인터페이스를 일반적으로 스프링 컨테이너라 함.

1. BeanFactory

   1. 스프링 컨테이너의 최상위 인터페이스로 스프링 빈을 관리하고 조회하는 역할을 담당 - getBean() 메서드 제공 주체

      ✨✨✨✨✨✨✨✨✨✨✨✨✨✨

      

2. ApplicationContext 인터페이스

   

   • ApplicationContext는 BeanFactory로 부터 확장된 인터페이스 뿐만 아니라 EnvironmentCapable, MessageSource, ApplicationEventPublisher, ResourcePatternResolver 등 다양한 기능의 인터페이스들을 상속 받아 사용 (인터페이스는 다중 상속이 가능, 앞 뒤 전부다 인터페이스 임을 알 수 있음)
   • 이러한 인터페이스들은 환경 변수 설정, 메시지 국제화 기능, 이벤트 발생, 리소스 조회 등 다양한 기능들을 지원
   • 즉, ApplicationContext는 빈을 관리하고 조회하는 기능 뿐 아니라 웹 애플리케이션을 개발하는 데 필요한 다양한 부가 기능들을 함께 제공

   스프링 컨테이너는 우리가 했던 것처럼 애너테이션 기반 자바 설정 클래스로도 만들 수 있지만, XML(Extensible Markup Language)를 기반으로 생성하는 것도 가능 XML은 데이터를 정의하는 규칙을 제공하는 마크업 언어로서, 컴퓨터 시스템 간의 공유 가능한 방식으로 데이터를 정의하고 저장할 수 있음

3. AnnotationConfigApplicationContext
   • 그 구현 객체이며 매개변수로 구성 정보(AppConfig.class)를 넘겨주고 있음.

스프링 컨테이너와 빈

1. 스프링 컨테이너는 이렇게 넘겨받은 구성 정보를 가지고 메서드들을 호출하여 빈을 생성하고, 빈들 간의 의존 관계를 설정
2. 빈을 생성하는 과정에서, 스프링 컨테이너는 호출되는 메서드의 이름을 기준으로 빈의 이름을 등록
   • 예를들어 discountPolicy() 메서드의 호출결과로
   • 반환된 new FixedAmountDiscountPolicy(100) 객체 빈은

   • discountPolicy 라는 이름으로 스프링컨테이너에 저장됨.

       @Configuration
       public class AppConfig {
             
           @Bean
           public DiscountPolicy discountPolicy() {
               return new FixedAmountDiscountPolicy(100); // 할인 금액을 여기서 설정
           }
     

3. 빈 이름 설정과 조회

   1. 설정 : @Bean(name=”~”)

       @Configuration
       public class AppConfig {
              
           @Bean(name="discountPolicy2")
           public DiscountPolicy discountPolicy() {
               return new FixedAmountDiscountPolicy(100); // 할인 금액을 여기서 설정
           }
              
      

      • 만약 위와 같은 방식으로 빈의 이름을 등록해 줄 시, 같은 이름의 빈이 등록되는 경우 에러의 원인이 되므로, 항상 다른 이름의 빈을 생성하도록 주의

   2. 조회

      • 빈은 클래스의 등록 정보, getter/setter 메서드를 포함하며, 앞서 본 것처럼 구성 정보(설정 메타 정보)를 통해 생성

        

      • 우리가 넘긴 구성 정보를 토대로 스프링 컨테이너가 빈을 생성하고 의존 관계를 연결해 주면 이제 스프링 컨테이너의 관리 하에 있는 객체 빈들을 아래와 같이 getBean() 메서드로 조회가능

      • getBean(빈 이름, 타입) 또는 getBean(타입)

          DiscountPolicy discountPolicy 
          	= applicationContext.getBean("discountPolicy", DiscountPolicy.class);
                    	
          	또는 
                    	
          	= applicationContext.getBean(DiscountPolicy.class);
        

        1. getBean(타입)으로 bean 조회시 같은 타입의 객체가 두 개 이상 있는 경우 오류 발생
4. Main 실행 클래스

   1. 모든 빈 조회

       public class Main {
           public static void main(String[] args) {
              
       			// (2) 모든 빈 조회
       	    ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfigurer.class);
              
       			String[] beanDefinitionNames = applicationContext.getBeanDefinitionNames();
              
       				for (String beanDefinitionName : beanDefinitionNames) {
                   Object bean = applicationContext.getBean(beanDefinitionName);
                   System.out.println("beanName=" + beanDefinitionName + " object=" + bean);
               }
       }
              
      

      • getBeanDefinitionNames() 메서드 사용시 스프링컨테이너가 관리하는 모든 빈 조회 가능

   2. 빈 메타 정보 조회

       public class Main {
           public static void main(String[] args) {
              
       			// (2) 빈 메타정보 조회
       			AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfigurer.class);
              
       			String[] beanDefinitionNames = applicationContext.getBeanDefinitionNames();
              
               for (String beanDefinitionName : beanDefinitionNames) {
                   BeanDefinition beanDefinition = applicationContext.getBeanFactory().getBeanDefinition(beanDefinitionName);
                   System.out.println("Bean name: " + beanDefinitionName + ", Scope: " + beanDefinition.getScope());
               }
       }
              
      

      
      

테스트 케이스 작성 기초

1. 단위테스트
   1. 작은 단위의 어떤 특정한 기능을 테스트하고, 검증하기 위한 도구를 의미
   2. = 테스트 케이스(Test Case)를 작성한다고도 표현
   3. 입력 데이터, 실행 조건, 그리고 기대 결과에 대한 값이 포함
   4. 스프링에서 JUnit이라는 오픈 소스 테스트 프레임워크를 제공
      1. 각각의 단위 테스트는 메서드 단위로 작성
2. JUnit
   1. test 디렉토리 안에서 작성되는 것을 원칙
   2. 테스트 클래스는 관례적으로 테스트의 대상이 되는 클래스의 이름에 Test를 붙여 클래스를 생성

   3. 기본구조- 각 검증하고자 하는 기능 단위에 따라 메서드로 작성

       import org.junit.jupiter.api.Test;
              
       public class JunitDefaultStructure {
              
           @Test
           public void test1() {
            // 테스트하고자 하는 대상에 대한 테스트 로직 작성
           }
              
           @Test
           public void test2() {
            // 테스트하고자 하는 대상에 대한 테스트 로직 작성
           }
              
           @Test
           public void test3() {
            // 테스트하고자 하는 대상에 대한 테스트 로직 작성
           }
       }
              
      

      
      
      
      

테스트 로직 작성

1. 예제 -MainTest 클래스 - 빈 조회 단위 테스트 작성

    package com.springboot.v2;
       
    import com.springboot.v2.discount.DiscountPolicy;
    import org.assertj.core.api.Assertions;
    import org.junit.jupiter.api.Test;
    import org.springframework.context.annotation.AnnotationConfigApplicationContext;
       
    import static org.junit.jupiter.api.Assertions.*;
       
    class KioskApplicationTest {
        // 스프링 컨테이너 생성
        AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
       
        // 빈 조회 테스트케이스
        @Test
        void findBean() {
       
            // (1) given => 초기화 또는 테스트에 필요한 입력 데이터
            AnnotationConfigApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
       
            // (2) when => 테스트 할 동작
            DiscountPolicy discountPolicy = applicationContext.getBean("discountPolicy", DiscountPolicy.class);
       
            // (3) then => 검증
            Assertions.assertThat(discountPolicy).isInstanceOf(DiscountPolicy.class);
        }
    }
   

2. 테스트 실행

   

3. 출력

   

4. 비즈니스 로직

   1. given - when - then 은 BDD(Behavior Driven Development)라고 부르는 테스트 방식에서 사용되는 방법

   (1) given: 입력 데이터

   • 테스트에 필요한 초기화 값 또는 입력 데이터를 의미
   • 위의 예제의 경우, 빈 조회 테스트에 필요한 초기화 세팅은 AppConfigurer 클래스를 구성 정보로 하는 스프링 컨테이너를 생성하는 것

   (2) when: 실행 동작

   • 테스트할 실행 동작을 지정.
   • 빈 조회 테스트에서 실행할 동작은 getBean() 메서드를 사용하여 빈을 불러오는 것

   (3) then: 결과 검증

   • 테스트의 결과를 최종적으로 검증하는 단계
   • 일반적으로 테스트 결과 예상되는 기대값(expected)과 실제 실행 결과의 값을 비교하여 테스트를 검증
   • 주로 JUnit 또는 AssertJ 라이브러리에서 제공하는 Assertions 클래스의 기능들을 필요에 따라 사용하여 검증을 진행함
   • 위의 코드는 AssertJ 라이브러리의 Assertions 클래스의 메서드인 assertThat()을 사용한 검증 방법
   • AssertJ는 메서드 체이닝(method chaining)을 지원하기 때문에 스트림과 유사하게 여러 메서드들을 연속하여 호출하여 간편하게 사용이 가능
   • AssertJ에서 모든 테스트코드는 assertThat()을 사용하고, 테스트를 실행할 대상을 파라미터로 전달하여 호출, 호출의 결과로 ObjectAssert 타입의 인스턴스를 반환하는데, 이를 사용하여 isInstanceOf() , isSameAs() , isNotNull() , isNotEmpty() 등 다양한 검증을 편리하게 실행가능.
   • 우리가 작성한 코드를 해석해 보면, 먼저 Assertions.assertThat() 메서드에 테스트를 실행할 참조변수 discountPolicy를 전달인자로 전달하고, 메서드 체이닝을 사용하여 isInstanceOf() 메서드를 사용하고 있음
   • isInstanceOf() 메서드는 대상 타이 주어진 유형의 인스턴스인지 검증할 때에 사용, 자바의 instanceOf() 메서드와 유사하다고 할 수 있습니다.

스프링컨테이너(=Singleton container)- 이해안감

1. 스프링 컨테이너는 싱글톤 컨테이너 역할을 수행
2. 스프링 컨테이너는 싱글톤 레지스트리 기능을 가지고 있는 싱글톤 컨테이너이기 때문에 그 안에서 생성되고 관리되는 객체들이 싱글톤으로 관리됨

3. 싱글톤으로 객체를 생성 및 관리하는 기능을 싱글톤 레지스트리(Singleton Registry)

   

4. 싱글톤패턴
   1. 특정 클래스의 인스턴스가 단 하나만 생성되도록 보장하는 디자인 패턴
   2. 고객의 요청마다 new 연산자를 사용하여 객체를 생성하면 큰 메모리 낭비를 초래.
   3. 싱글톤 패턴을 구현하여 최초에 단 하나의 객체를 생성하고 요청이 있을 때마다 같은 객체를 공유하는 방법으로 메모리 낭비를 최소화 하는 것이 가능.

5. 예제 : 싱글톤을 적용하여 작성한 테스트 코드

    import org.assertj.core.api.Assertions;
    import org.junit.jupiter.api.Test;
       
    public class SingletonTest {
       
        // 싱글톤 구현 O
        @Test
        void runWithSingleton() {
       
            TestConfig2 testConfig2 = new TestConfig2();
       
    				// productRepository 객체 생성
            ProductRepository productRepository = testConfig2.productRepository();
            ProductRepository productRepository2 = testConfig2.productRepository();
       
            // 생성한 두 개의 객체가 같은 참조값을 가지고 있는지 검증
            Assertions.assertThat(productRepository).isSameAs(productRepository2);
        }
       
        // 테스트를 위한 TestConfig2 클래스
        static class TestConfig2 {
       
            private final ProductRepository productRepository = new ProductRepository();
       
            private TestConfig2(){}
       
            public ProductRepository productRepository() {
                return productRepository;
            }
        }
    }
       
   

   문제점

   • 싱글톤 패턴을 사용하면 반복적으로 사용되는 객체를 매번 새롭게 생성하지 않고 하나의 객체를 공유하여 메모리 낭비를 최소화
   • 지양하는 것이 좋음 ⇒ 객체 간 높은 결합도가 야기되기 때문
   • 또한 private final 사용으로 변경과 확장의 어려움

빈 생명주기와 범위

스프링 컨테이너는 크게 초기화와 종료라는 생명 주기(life-cycle)를 가짐

1. 빈 객체 생명 주기

   

   (1) 가장 먼저 빈 객체들을 생성

   (2) 객체들 간 의존 관계를 설정

   (3) 의존 관계 설정이 완료되면 내부적으로 지정한 메서드를 호출하여 빈 객체의 초기화를 진행

   (4) 빈 객체들의 사용이 마무리되고 스프링 컨테이너가 종료되면, 스프링 컨테이너는 지정한 메서드를 호출하여 빈 객체들의 소멸을 처리

2. 스프링 컨테이너와 빈 객체 생명주기 이해 필요성

   1. 필요한 기능 구현을 하기 위함

      Ex) 데이터베이스의 커넥션 풀, 채팅 클라이언트의 기능 등의 구현

      1. 커넥션 풀을 위한 빈 객체는 데이터베이스를 연결하며, 채팅 클라이언트는 서버와의 연결을 진행
      2. 반대로, 컨테이너가 종료되어 빈 객체가 소멸되는 시점에서는 데이터베이스 또는 서버와의 연결을 적절하게 끊어낼 수 있어야 함
3. 스프링은 의존 관계 설정이 완료된 시점과 스프링 컨테이너의 종료 직전의 시점에 지정된 메서드를 호출하여 개발자로 각각의 시점에 필요한 작업을 수행할 수 있도록 지원

   1. InitializingBean & DisposableBean 인터페이스

       // 초기화 단계에서 실행되는 메서드
       public interface InitializingBean {
       	void afterPropertiesSet() throws Exception;
       }
              
       // 소멸 단계에서 실행되는 메서드
       public interface DisposableBean {
       	void destroy() throws Exception;
       }
      

      • 빈 객체가 InitialzingBean과 DisposableBean 인터페이스를 구현 ⇒ 스프링 컨테이너는 초기화 과정과 소멸 과정에서 각각 빈 객체의 afterPropertiesSet() 메서드와 destroy() 메서드를 실행

      • 예제

          public class TestClient implements InitializingBean, DisposableBean {
                    
              private String url;
                    
              public TestClient(String url) {
                  System.out.println("생성자 호출.");
                  this.url = url;
              }
                    
          		@Override
              public void afterPropertiesSet() throws Exception {
                  System.out.println("초기화 메서드 실행.");
              }
                    
              public void connect() {
                  System.out.println("클라이언트를 " + url + "로 연결.");
              }
                    
          		@Override
              public void destroy() throws Exception {
                  System.out.println("종료 메서드 실행.");
              }
          }
                    
        

      • but, 문제점 O ⇒ 스프링 전용 인터페이스이기 때문에, 초기화와 소멸 메서드의 이름을 개발자가 임의로 변경불가 / 직접 구현한 클래스가 아닌 외부에서 받은 라이브러리나 클래스 등에 두 가지 인터페이스를 적용할 수 있는 방법이 없음

   2. 문제점 보완, 인터페이스를 구현하는 부분을 삭제, init()과 close() 메서드

       public class TestClient {
              
           private String url;
              
           public TestClient(String url) {
               System.out.println("생성자 호출.");
               this.url = url;
           }
              
           public void init() {
               System.out.println("init() 초기화 메서드 실행.");
           }
              
           public void connect() {
               System.out.println("클라이언트를 " + url + "로 연결.");
           }
              
           public void close() {
               System.out.println("close() 종료 메서드 실행.");
           }
              
       }
              
       ----------------------------------------------------------------
              
       @Configuration
       public class ClientConfig {
              
           @Bean(initMethod = "init", destroyMethod = "close")
           public TestClient testClient() {
               TestClient testClient = new TestClient("www.naver.com");
               return testClient;
           }
       }
              
      

   3. @PostConstruct와 @PreDestory 애너테이션을 활용 : 최신 스프링에서 가장 권장하는 방법

       public class TestClient {
              
           private String url;
              
           public TestClient(String url) {
               System.out.println("생성자 호출.");
               this.url = url;
           }
              
           @PostConstruct
           public void init() {
               System.out.println("init() 초기화 메서드 실행.");
           }
              
           public void connect() {
               System.out.println("클라이언트를 " + url + "로 연결.");
           }
              
           @PreDestroy
           public void close() {
               System.out.println("close() 종료 메서드 실행.");
           }
       }
      

4. 빈 객체의 관리 범위
   1. 빈 객체의 스코프란 이름 그대로 빈 객체가 존재할 수 있는 범위를 의미
   2. 스프링 컨테이너 안에서 관리되는 스프링 빈도 스프링 컨테이너의 생성과 종료와 함께 운명을 같이 함

   3. 빈 객체의 관리 범위에는 싱글톤 외에도 프로토타입(prototype), 세션(session), 리퀘스트(request) 등의 범위가 존재

      ScopeTest 클래스

       public class ScopeTest {
              
           @Test
           public void scopeTest() {
               // 컨테이너 생성
               AnnotationConfigApplicationContext annotationConfigApplicationContext = new AnnotationConfigApplicationContext(TestBean.class);
              
               // 컨테이너 사용
               TestBean bean = annotationConfigApplicationContext.getBean(TestBean.class);
               TestBean bean2 = annotationConfigApplicationContext.getBean(TestBean.class);
              
               System.out.println("bean = " + bean);
               System.out.println("bean2 = " + bean2);
              
               // 검증
               Assertions.assertThat(bean).isSameAs(bean2);
              
               // 컨테이너 종료
               annotationConfigApplicationContext.close();
           }
              
           static class TestBean {
              
               // 초기화 메서드 설정
               @PostConstruct
               public void init() {
                   System.out.println("init() 초기화 메서드 실행.");
               }
              
               // 종료 메서드 설정
               @PreDestroy
               public void close() {
                   System.out.println("close() 종료 메서드 실행.");
               }
           }
       }
              
      

      • prototype으로 검사하고 싶으면 TestBean 클래스 위에 @Scope("prototype") 애너테이션 붙이면 됨.

컴포넌트 스캔과 의존성 자동 주입

1. @Configuration과 @Bean을 사용한 수동 주입 방식
   1. 빈의 수가 많을 경우 번거로움.
2. 컴포넌트 스캔 @ComponentScan
   1. 자동으로 스프링 빈을 등록하는 기능, 구체적인 의존 관계 설정이 불가능
   2. 범위 변경하고 싶으면 @ComponentScan(basePackages = “”) 에서 “” 부분에 패키지 이름을 표시
   3. @Configuration 애너테이션,@Controller, @Service, @Repository 등의 애너테이션도 컴포넌트 스캔의 대상에 포함
3. @Autowired 애너테이션
   1. 빈을 자동으로 등록함과 동시에 의존 관계가 설정
   2. 생성자가 단 하나만 존재하는 경우에는 @Autowired 애너테이션을 붙이지 않아도 자동으로 의존 관계가 연결

### comment

너무 어렵다,, singleton부터는 이해가 잘 안가서 연휴에 다시 보고 다른 자료도 찾아봐야 할 것 같다
그리고 강사님은 별말 없으시긴 했는데….저기 사용된 코드도 한번은 따라 쳐보는게 낫겟지? !

---

Spring 카테고리 내 다른 글 보러가기