Spring (2)

0. 지극히 개인적인 정리

 

1. ApplicationContext interface

 1) @Configuration이 붙은 구성 정보 내 @Bean을 죄다 찾아서 spring container에 담음

 2) spring bean: spring container에 담긴(등록된) 객체

  (1) 상위의 타입으로 조회하면 연결된 하위 타입을 싹 다 조회

 3) 필요한 경우 ApplicationContext interface 내 getBean method로 spring bean 안에 있는 정보를 꺼내서 사용

 

2. BeanFactory

 1) spring container 내 최상위 interface로 bean을 관리하고 조회

 2) ApplicationContext는 BeanFactory를 모두 상속받음 -> bean 관리하고 조회하고 부가기능이 포함됨

  (1) 부가기능1: 메시지 소스 - 한국어, 영어 등 해당국가에서 진입 시 해당언어로 메시지 호출

  (2) 부가기능2: 환경변수 - local, dev, stg, prd 등 환경에 따라 구분하여 처리할 것들 정의

  (3) 부가기능3: 애플리케이션 이벤트 처리

  (4) 부가기능4: 편리한 리소스 조회 - file, classpath를 관리하고 외부에서 리소스를 편리하게 조회

 

3. annotation 기반으로 자바 코드를 설정 = XML 설정

 1) new 연산자를 활용하여 AnnotationConfigApplicationContext(설정정보클래스) -> Java code로 된 설정 정보 넘김

 2) spring boot의 사용으로 최근에는 XML 설정을 거의사용하지 않게 됨

 

4. BeanDefinition

 1) spring이 지원하는 bean 설정 meta 정보: Java code, XML ... 등  다양한 형식으로 설정을 지원하는 이유

 2) 다양한 설정 정보를 BeanDefinition으로 추상화해서 사용

 

5. singleton pattern

 1) 같은 내용의 method를 계속해서 호출해야 하는 경우

     new 연산자로 객체를 마구 찍어내면 결국 memory 부하 및 리소스 낭비

 2) 이럴때 객체를 하나만 만들어서 재사용하자! -> 이것이 바로 효율적인 자원 관리 아닐까?

 3) 작성방식

  (1) class의 instance가 1개만 생성되는 것을 보장하는 design pattern

  (2) static으로 객체를 생성

  (3) getInstance() method를 이용하여 객체가 필요하면 자신을 return 하도록 설정

   - 이 객체가 필요하다 = getInstance() method로만 호출이 가능

  (4) private 속성으로 constructor method를 생성

   - 외부에서 new 연산자로 객체를 생성하여 호출하는 방식이 불가능 

  (5) 항상 같은 instance를 return

 4) 문제점

  (1) 구현 코드를 작성하는 것 자체가 일이다

  (2) DIP 및 OCP 위반: 구체화된 class에 의존

  (3) 유연성 저하: 필히 작성해야하는 코드의 방식이 정해져 있음

 5) singleton container

  (1) spring container는 singleton pattern을 적용하지 않아도 instance를 singleton으로 관리

  (2) spring container는 singleton container 역할을 담당 = singleton registry

  (3) singleton pattern의 단점인 코드 패턴, DIP 및 OCP 위반 등 단점을 극복

 6) 주의점

  (1) 여러개의 client가 하나의 instance를 공유 -> spring bean은 무상태(stateless)로 설계

   - 특정 client에 의존하면 안됨

   - 가급적 읽기만 가능해야 함

 

  ※ @Bean이 붙은 method를 다 뒤진 결과 동일한 spring bean이 이미 존재하면 이미 존재하는 bean을 return

     없으면 spring bean으로 등록하고 새로운 bean을 return

  ※ @Configuration을 통해 바이트 코드를 조작하는 CGLIB 기술을 사용해서 singleton을 보장하지만, @Configuration

     를 제외하고 @Bean만 적용하면 CGLIB 기술을 사용하지 않는 순수하게 작업한 bean이 호출

      -> new 연산자로 instance 생성 = singleton 깨짐