코멘토 실무PT 후기 챌린지 1주차 - 스프링 프레임워크(DI와 IoC)

(1) 스프링 프레임워크 개념

 1) DI

- UserController 클래스에서 userService를 직접 생성해서 주입받고있음.

- UserService 에서는 jdbcUserRepository를 직접 생성해서 주입받고있음.

 

만약 JdbcUserRepository를 다른 객체로 받고 싶다면 기존 코드를 지우고 새로운 객체를 생성하여 주입받아야함으로 클라이언트를 변경해야하는 OCP를 위반하고 있음.

 

이를 보완하기위해서, 인터페이스를 통하여 연관관계 구조를 인터페이스 형태를 통하여 주입받는 구조로 재구성.

UserService 인터페이스 생성

UserRepository 인터페이스 생성

Impl 객체를 통해서 구현객체 생성

생성자 매개변수를 통하여 의존관계를 주입받도록 함

인터페이스를 통하여 객체를 주입을 받아도 

- Controller에서 Repository와 Service를 생성하여 의존성을 주입하면서 개발자가 직접 관여하고있는 문제점이 발생하고 아직도 클라이언트를 변경해야하는 구조적인 문제가 발생함.

이를 IoC 컨테이너를 통하여 프레임워크를 통하여 제어를 역전하도록 변경하려고 한다.

 

2) IoC

IoC란, 제어의 역전이라고 하며 메소드나 객체의 호출작업을 개발자가 직접 결정하는 것이아니라 프레임웤를 통하여 외.부에서 결정하는 방식을 말함.

APplicationContext를 통하여 IoC를 수행

IoC 컨테이너란, 인스턴스 생성하며 의존관계 설정, 빈을 제공한다.

UserServiceImpl이 생성 될때 UserRepository의 구현 클래스가 자동으로 생성되어 주입됨.

@Configuration 어노테이션을 붙여 설정 클래스로 선언.

AppConfig를 통해서 의존관계 주입. 파라미터를 추가하는 방식으로 의존성 주입.

- 파라미터로 전달되는 인스턴스는 빈으로 설정되어있어야 함.

 

3) DI 방식

 (1) 필드기반 주입

필드기반 의존성주입(@Autowired)

 

 (2) 일반 메소드 주입

일반 메소드 주입

- Init 메소드를 통하여 DI 

- 주입관계가 변경될 가능성이 있음.

 

 (3) 생성자 주입

생성자 주입

- Impl이 호출될 때 자동으로 생성자 주입

생성자 주입이 권고되는 이유

 - 대부분의 의존관계 주입은 한번 일어나면 Application 종료시점까지 의존관계를 변경할 일 이 없음 또한, 대부분의 의존관계는 Application 종료 전까지 변하면 안됨(불변)

 - 주입을 변경하는 구조는 좋은 설계방식이 아니다.

생성자 주입은 객체를 생성할 때 1번만 호출되므로 이후에 호출되는 일이 없고 변경할 수 없음.

 

코멘토링크 : https://comento.kr/