WebFramework/SpringBoot

[강의] 스프링 IoC 컨테이너

데이25 2020. 1. 13. 23:16

스프링 IoC 컨테이너

장점

  1. 빈으로 등록 > 싱글톤

  2. Annotation 사용

    • ApplicationContext : ResourceLoader 빈 팩토리에 비해 더 많은 기능 가지고 있음.

    • 기본값은 singleton

  3. 빈 주입은

    • property name && ref 써서 주입한다.

    • setBean을 해줘서 값을 꺼내올수 있음(xml 파일에서 )

  4. Componant

  5. Inject :

  6. Autowired :

  7. Configuration

    • 자바 설정으로 일일이 할수도 있음 : @bean 쓰고 함.

  8. (@ComponentScan : basePackageClasses = [springboot].class) :: 이 이하 클래스들 모두 스캔한다.

빈

<spring bean>

  • pojo (plain, old java object) / 애플리케이션의 핵심을 이루는 객체

  • 컨테이너에 의해 인스턴스화, 관리, 생성

  • xml 파일에 의해 생성.

  • getBean 통해서 가져옴

싱글톤

  • 싱글톤으로 적합한 객체

    • 상태가 없는 공유 객체: 상태를 가지고 있지 않은 객체는 동기화 비용이 없다. 따라서 매번 이 객체를 참조하는 곳에서 새로운 객체를 생성할 이유가 없다.

    • 읽기용으로만 상태를 가진 공유 객체: 1번과 유사하게 상태를 가지고 있으나 읽기 전용이므로 여전히 동기화 비용이 들지 않는다. 매 요청마다 새로운 객체 생성할 필요가 없다.

    • 공유가 필요한 상태를 지닌 공유 객체: 객체 간의 반드시 공유해야 할 상태를 지닌 객체가 하나 있다면, 이 경우에는 해당 상태의 쓰기를 가능한 동기화 할 경우 싱글톤도 적합하다.

    • 쓰기가 가능한 상태를 지니면서도 사용빈도가 매우 높은 객체: 애플리케이션 안에서 정말로 사용빈도가 높다면, 쓰기 접근에 대한 동기화 비용을 감안하고서라도 싱글톤을 고려할만하다. 이 방법은 1. 장시간에 걸쳐 매우 많은 객체가 생성될 때, 2. 해당 객체가 매우 작은 양의 쓰기상태를 가지고 있을 때, 3. 객체 생성비용이 매우 클 때에 유용한 선택이 될 수 있다.

  • 비싱글톤으로 적합한 객체

    • 쓰기가 가능한 상태를 지닌 객체: 쓰기가 가능한 상태가 많아서 동기화 비용이 객체 생성 비용보다 크다면 싱글톤으로 적합하지 않다.

    • 상태가 노출되지 않은 객체: 일부 제한적인 경우, 내부 상태를 외부에 노출하지 않는 빈을 참조하여 다른 의존객체와는 독립적으로 작업을 수행하는 의존 객체가 있다면 싱글톤보다 비싱글톤 객체를 사용하는 것이 더 나을 수 있다.

setter 에 @autowired 쓰는 경우 : 해당 빈을 찾아서 ? bookservice 인터페이스 만들기는 가능.

생성자 사용한 의존성 주입 : book service

@Primary 어노테이션 : 가장 먼저 의존 주입할 부분.

@Qualifier 빈의 이름

  • List<BookRepository> bookRepositor

빈 만들어지고 난 이후에 부가적인 작업

컨테이너

인스턴스의 생명주기 관리.

ex) servlet 실행 was는 servlet 컨테이너 갖고 있다 라고 말한다.

보통 인스턴스의 생명주기를 관리, 생성된 인스턴스 들에게 추가적인 기능 제공하는것

IoC

컨테이너가 코드 대신 오브젝트의 제어권 갖고있는 제어의 역전이라한다.

서블릿의 메소드를 알맞게 호출하는 것은 was과 같음. 이렇게 개발자가 만든 클래스, 메소드를 다른 프로그램이 대신 실행시켜주는 것.

DI

의존성 주입. 클래스 사이 의존관계를 빈 설정을 바탕으로 컨테이너가 자동으로 연결해주는 것.

스프링이 컨테이너 인것

Spring 에서 제공하는 IoC/DI 컨테이너

  • BeanFactory : IoC/ DI 기본기능

  • ApplicationContext : BeanFactory의 모든 기능 포함.

  • BeanPostProcessor : 컨테이너의 로직을 오버라이딩해서 인스턴스화 와 의존성 처리 로직 등을 개발자가 원하는대로 구현.

  • BeanFactoryPostProcessor : 설정된메타데이터 커스터마이징.

<componant-scan>

패키지 내부만 가능

빈 주입이 잔ㄹ 안된다하면 -> componant scan 범위, filter 범위 확인