[내일배움캠프_Spring Boot 입문주차] IoC와 DI

IoC(제어의 역전), DI(의존성 주입) 이해하기

Spring의 IoC와 DI

﹡IoC와 DI는 객체지향의 SOLID 원칙 혹은 GoF의 디자인 패턴과 같은 설계 원칙 및 디자인 패턴임

IoC는 설계 원칙에 해당하고, DI는 디자인 패턴에 해당함

ex) 설계 원칙과 디자인 패턴을 요리에 빗대어보기

김치 볶음밥 맛있게 만드는 방법(설계 원칙)
- 신선한 재료 사용
- 신 김치 사용
김치 볶음밥 레시피(디자인 패턴)
1. 오일을 두른 팬에 채썬 파를 볶아 파기름을 만든다.
2. 준비한 햄을 넣고 볶다고, 간장 한스푼을 넣어 풍미를 낸다.
...

좋은 코드를 위해서 Spring에서 IoC와 DI를 제공하고 있음

❓ 좋은 코드란?
- 논리가 간단해야함
- 중복을 제거하고 표현을 명확하게 함
- 코드를 처음 보는 사람도 쉽게 이해하고 수정할 수 있어야 함
- 의존성을 최소화해야 함
- 새로운 기능을 추가 하더라도 크게 구조의 변경이 없어야 함

즉, IoC와 DI는 좋은 코드 작성을 위한 Spring의 핵심 기술 중 하나임!

의존성

ex) 다리를 다쳐서 목발을 사용해 걷게 된다면 걷기 위해 목발에 의존하고 있는 것임. 즉, 사람이 목발에 의존성을 두게 되었다고 할 수 있음

ex) 강하게 결합되어있는 Consumer와 Chicken

public class Consumer {
    void eat() {
    	Chicken chicken = new Chicken();
        chicken.eat();
    }
    
    public static void main(String[] args) {
    	Consumer consumer = new Consumer();
        consumer.eat();
    }
}

class Chicken {
	public void eat() {
    	System.out.println("치킨을 먹는다.");
    }
}

실행되는데 문제는 없지만, 중간에 Chicken이 아닌 Pizza 클래스를 넣고 싶은 경우 메서드를 수정해야함.
즉, 아래 코드 부분이 두 객체 사이에 강하게 결합되어 있음 → 바꾸려면 저 부분을 계속 수정해야함

public class Consumer {
    // 이 부분
    void eat() {
    	Chicken chicken = new Chicken();
        chicken.eat();
    }
    
	...
}

결합 약하게 만들기 ▶︎ Java의 Interface 활용

public class Consumer {
    // 메서드에서 인터페이스를 받음
    void eat(Food food) {
    	food.eat();
    }
    
    public static void main(String[] args) {
    	Consumer consumer = new Consumer();
        // 외부에서 new 하면서 객체 구현체 넣기
        consumer.eat(new Chicken());
        consumer.eat(new Pizza());
    }
}

interface Food {
	void eat();
}

class Chicken implements Food {
	@Override
    public void eat() {
    	System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {
	@Override
    public void eat() {
    	System.out.println("피자를 먹는다.");
    }
}

주입

코드에서 여러 방법을 통해 필요로 하는 객체를 해당 객체에 전달하는 것

필드에 직접 주입

public class Consumer {
    Food food; // Food 인터페이스를 Consumer 클래스가 필드로 갖기(default 접근제어자)

    void eat() {
    	this.food.eat();
    }
    
    public static void main(String[] args) {
    	Consumer consumer = new Consumer();
        consumer.food = new Chicken(); // 접근 가능
        consumer.eat();
        
        consumer.food = new Pizza();
        consumer.eat();
    }
}

interface Food {
	void eat();
}

class Chicken implements Food {
	@Override
    public void eat() {
    	System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {
	@Override
    public void eat() {
    	System.out.println("피자를 먹는다.");
    }
}

메서드를 통한 주입

public class Consumer {
    Food food;
    
    void eat() {
    	this.food.eat();
    }
    
    // 메서드로 구현체를 받아와 필드에 주입
    public void setFood(Food food) {
    	this.food = food;
    }
    
    public static void main(String[] args) {
    	Consumer consumer = new Consumer();
        consumer.setFood(new Chicken());
        consumer.eat();
        
        consumer.setFood(new Pizza());
        consumer.eat();
    }
}

interface Food {
	void eat();
}

class Chicken implements Food {
	@Override
    public void eat() {
    	System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {
	@Override
    public void eat() {
    	System.out.println("피자를 먹는다.");
    }
}

생성자를 통한 주입

public class Consumer {
    Food food;
    
    // Consumer 생성자 구현
    public Consumer(Food food) {
    	this.food = food;
    }

    void eat(Food food) {
    	this.food.eat();
    }
    
    public static void main(String[] args) {
    	// 생성자 호출 시, Food에 구현체 넣음
    	Consumer consumer = new Consumer(new Chicken());
        consumer.eat();
        
        consumer = new Consumer(new Pizza());
        consumer.eat();
    }
}

interface Food {
	void eat();
}

class Chicken implements Food {
	@Override
    public void eat() {
    	System.out.println("치킨을 먹는다.");
    }
}

class Pizza implements Food {
	@Override
    public void eat() {
    	System.out.println("피자를 먹는다.");
    }
}

제어의 역전(IoC)

위에서 강한 결합된 Consumer가 직접 Food를 만들어 먹었음
- 새로운 음식을 만들려면 추가적인 코드 수정 필요했음
- 제어의 흐름: Consumer → Food, 즉 Consumer가 Food를 직접 제어
이를 해결하기 위해서, 생성자를 통한 주입과 같이 외부에서 구현체를 주입받음
- 제어의 흐름: Food → Consumer(main인 외부에서 Consumer로 음식 집어넣음)로 역전됨

메모장 프로젝트의 IoC와 DI

문제점 1) 객체 생성 중복 코드 존재

package com.sparta.memo.service;


import com.sparta.memo.dto.MemoRequestDto;
import com.sparta.memo.dto.MemoResponseDto;
import com.sparta.memo.entity.Memo;
import com.sparta.memo.repository.MemoRepository;
import org.springframework.jdbc.core.JdbcTemplate;

import java.util.List;

public class MemoService {
    private final JdbcTemplate jdbcTemplate; // jdbcTemplate 변수 선언

    // 초기화를 위한 생성자
    // 외부에서 만들어져 있는 JdbcTemplate을 여기에 넣어줌
    // JdbcTemplate 객체는 Spring에서 따로 관리해주고 있음
    public MemoService(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    public MemoResponseDto createMemo(MemoRequestDto requestDto) {
        // RequestDto -> Entity
        Memo memo = new Memo(requestDto);

        // DB 저장
        MemoRepository memoRepository = new MemoRepository(jdbcTemplate);
        ...
    }

    public List<MemoResponseDto> getMemos() {
        // DB 조회
        MemoRepository memoRepository = new MemoRepository(jdbcTemplate);
        ...
    }

    public Long updateMemo(Long id, MemoRequestDto requestDto) {
        MemoRepository memoRepository = new MemoRepository(jdbcTemplate);
        // 해당 메모가 DB에 존재하는지 확인
        ...
    }

    public Long deleteMemo(Long id) {
        MemoRepository memoRepository = new MemoRepository(jdbcTemplate);
        // 해당 메모가 DB에 존재하는지 확인
        ...
    }
}

MemoRepository memoRepository = new MemoRepository(jdbcTemplate);
위 코드가 계속 중복되고 있음

MemoService 클래스가 생성이 될 때 한 번만 MemoRepository를 만들어서 사용하면 훨씬 효율적임

package com.sparta.memo.service;


import com.sparta.memo.dto.MemoRequestDto;
import com.sparta.memo.dto.MemoResponseDto;
import com.sparta.memo.entity.Memo;
import com.sparta.memo.repository.MemoRepository;
import org.springframework.jdbc.core.JdbcTemplate;

import java.util.List;

public class MemoService {

    private final MemoRepository memoRepository;

    // MemoService가 생성이 될 때, 파라미터로 JdbcTemplate 받아오고
    // 딱 한 번만 MemoRepository를 만듦
    public MemoService(JdbcTemplate jdbcTemplate) {
        this.memoRepository = new MemoRepository(jdbcTemplate);
    }

    public MemoResponseDto createMemo(MemoRequestDto requestDto) {
        // RequestDto -> Entity
        Memo memo = new Memo(requestDto);

        // DB 저장
        Memo saveMemo = memoRepository.save(memo);

        // Entity -> ResponseDto
        MemoResponseDto memoResponseDto = new MemoResponseDto(memo);

        return memoResponseDto;
    }

    public List<MemoResponseDto> getMemos() {
        // DB 조회
        return memoRepository.findAll();
    }

    public Long updateMemo(Long id, MemoRequestDto requestDto) {
        // 해당 메모가 DB에 존재하는지 확인
        Memo memo = memoRepository.findById(id);
        if(memo != null) {
            // memo 내용 수정
            memoRepository.update(id, requestDto);
            return id;
        } else {
            throw new IllegalArgumentException("선택한 메모는 존재하지 않습니다.");
        }
    }

    public Long deleteMemo(Long id) {
        // 해당 메모가 DB에 존재하는지 확인
        Memo memo = memoRepository.findById(id);
        if(memo != null) {
            // memo 삭제
            memoRepository.delete(id);
            return id;
        } else {
            throw new IllegalArgumentException("선택한 메모는 존재하지 않습니다.");
        }
    }
}

package com.sparta.memo.controller;

import com.sparta.memo.dto.MemoRequestDto;
import com.sparta.memo.dto.MemoResponseDto;
import com.sparta.memo.service.MemoService;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api")
public class MemoController {
    private final MemoService memoService; // jdbcTemplate 변수 선언
    
    public MemoController(JdbcTemplate jdbcTemplate) {
        this.memoService = new MemoService(jdbcTemplate);
    }

    @PostMapping("/memos")
    public MemoResponseDto createMemo(@RequestBody MemoRequestDto requestDto) {
        return memoService.createMemo(requestDto);
    }

    @GetMapping("/memos")
    public List<MemoResponseDto> getMemos() {
        return memoService.getMemos();
    }

    @PutMapping("/memos/{id}")
    public Long updateMemo(@PathVariable Long id, @RequestBody MemoRequestDto requestDto) {
        return memoService.updateMemo(id, requestDto);
    }

    @DeleteMapping("/memos/{id}")
    public Long deleteMemo(@PathVariable Long id) {
        return memoService.deleteMemo(id);
    }
}

문제점 2) 강한 결합 존재

public MemoService(JdbcTemplate jdbcTemplate) {
    this.memoRepository = new MemoRepository(jdbcTemplate);
}

MemoService가 MemoRepository를 직접 만들고 있음. 즉, 제어 흐름이 MemoService → MemoRepository
MemoController도 MemoService를 직접 만들고 있음. 즉, 제어 흐름이 MemoController → MemoService

‼️ 강한 결합의 문제점

1. Controller1이 Service1 객체를 생성해 사용

public class Controller1 {
    private final Service1 service1;
    
    public Controller1() {
    	this.service1 = new Service1();
    }
}

2. Service1이 Repository1 객체를 생성해 사용

public class Service1 {
    private final Repository1 repository1;
    
    public Service1() {
    	this.repository1 = new Repository1();
    }
}

3. Repository1 객체 선언

public class Repository1 {...}

4. 만약 다음과 같이 변경된다면,

a. Repository1 객체 생성 시 DB 접속 id, pw를 받아서 DB 접속 시 사용(생성자에 DB 접속 id, pw 추가)

public class Repository1 {
	public Repository1(String id, String pw){
    	// DB 연결
        Connection connection = DriverManager.getConnection("~~", id, pw);
    }
}

Controller 5개가 각각 Service1을 생성해 사용 중일 경우, Repository1 생성자 변경에 의해 모든 Controller와 모든 Service의 코드 변경이 필요함

메모장 프로젝트에서도 MemoService에서 자신은 사용하지 않지만 MemoRepository를 사용하기 위해 MemoRepository의 생성자에 JdbcTemplate을 넣어주고 있음

마찬가지로 MemoController에서도 MemoService를 사용해야하기 때문에 생성자에 JdbcTemplate을 넣어주고 있음

public MemoController(JdbcTemplate jdbcTemplate) {
	this.memoService = new MemoService(jdbcTemplate);
}
...
public MemoService(JdbcTemplate jdbcTemplate) {
	this.memoRepository = new MemoRepository(jdbcTemplate);
}

강한 결합 해결

각 객체에 대한 객체 생성은 딱 1번만!
생성된 객체를 모든 곳에서 재사용!
생성자 주입을 사용해 필요로하는 객체에 해당 객체 주입

1. Repository1 클래스 선언 및 객체 생성 → repository1

public class Repository1 { ... }

// 객체 생성
Repository1 repository1 = new Repository1();

2. Service1 클래스 선언 및 객체 생성(repository1 사용) → service1

Class Service1 {
	private final Repository1 repository1;
    
    // repository1 객체 사용
    public Service1(Repository1 repository1) {
    	this.repository1 = repository1;
    }
}

// 객체 생성
Service1 service1 = new Service1(repository1);

3. Controller1 선언(service1 사용)

Class Controller1 {
	private final Service1 service1;
    
    // service1 객체 사용
    public Controller1(Service1 service1){
    	this.service1 = service1;
    }
}

강한 결합 → 느슨한 결합

메모장 프로젝트에 제어의 역전 적용하기

package com.sparta.memo.controller;

import com.sparta.memo.dto.MemoRequestDto;
import com.sparta.memo.dto.MemoResponseDto;
import com.sparta.memo.service.MemoService;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.web.bind.annotation.*;

import java.util.List;

@RestController
@RequestMapping("/api")
public class MemoController {
    private final MemoService memoService; // jdbcTemplate 변수 선언

    public MemoController(MemoService memoService) {
        this.memoService = memoService;
    }

    @PostMapping("/memos")
    public MemoResponseDto createMemo(@RequestBody MemoRequestDto requestDto) {
        return memoService.createMemo(requestDto);
    }

    @GetMapping("/memos")
    public List<MemoResponseDto> getMemos() {
        return memoService.getMemos();
    }

    @PutMapping("/memos/{id}")
    public Long updateMemo(@PathVariable Long id, @RequestBody MemoRequestDto requestDto) {
        return memoService.updateMemo(id, requestDto);
    }

    @DeleteMapping("/memos/{id}")
    public Long deleteMemo(@PathVariable Long id) {
        return memoService.deleteMemo(id);
    }
}

package com.sparta.memo.service;


import com.sparta.memo.dto.MemoRequestDto;
import com.sparta.memo.dto.MemoResponseDto;
import com.sparta.memo.entity.Memo;
import com.sparta.memo.repository.MemoRepository;

import java.util.List;

public class MemoService {

    private final MemoRepository memoRepository;

    // MemoService가 생성이 될 때, 파라미터로 JdbcTemplate 받아오고
    // 딱 한 번만 MemoRepository를 만듦
    public MemoService(MemoRepository memoRepository) {
        this.memoRepository = memoRepository;
    }

    public MemoResponseDto createMemo(MemoRequestDto requestDto) {
        // RequestDto -> Entity
        Memo memo = new Memo(requestDto);

        // DB 저장
        Memo saveMemo = memoRepository.save(memo);

        // Entity -> ResponseDto
        MemoResponseDto memoResponseDto = new MemoResponseDto(memo);

        return memoResponseDto;
    }

    public List<MemoResponseDto> getMemos() {
        // DB 조회
        return memoRepository.findAll();
    }

    public Long updateMemo(Long id, MemoRequestDto requestDto) {
        // 해당 메모가 DB에 존재하는지 확인
        Memo memo = memoRepository.findById(id);
        if(memo != null) {
            // memo 내용 수정
            memoRepository.update(id, requestDto);
            return id;
        } else {
            throw new IllegalArgumentException("선택한 메모는 존재하지 않습니다.");
        }
    }

    public Long deleteMemo(Long id) {
        // 해당 메모가 DB에 존재하는지 확인
        Memo memo = memoRepository.findById(id);
        if(memo != null) {
            // memo 삭제
            memoRepository.delete(id);
            return id;
        } else {
            throw new IllegalArgumentException("선택한 메모는 존재하지 않습니다.");
        }
    }
}

❓MemoService와 MemoRepository는 누가 어디서 만들어서 넣어준걸까?

IoC Container와 Bean

Spring IoC 컨테이너

외부에서 주입을 받는 의존성 주입 DI를 하기 위해서는 객체의 생성이 우선되어야 함

→ 현재 Controller 입장에서 만들어진 Service 객체를 받아서 필드에 넣어주고 있기 때문에, Service의 객체 생성이 우선되어야 한다는 뜻

﹡Spring프레임워크가 필요한 객체를 생성해주고 관리하는 역할을 대신해주고 있음

빈(Bean): Spring이 관리하는 객체

Spring IoC 컨테이너: 'Bean'을 모아둔 컨테이너

따라서, 생성자에서 외부에서 주입받을 때는 Bean 객체만 주입할 수 있음.

Spring Bean 등록과 의존성 주입

Bean 등록 ▶︎ @Component

Bean으로 등록하고자 하는 Class 위에 @Component 어노테이션 작성

@ComponentScan 어노테이션 존재 → @ComponentScan은 Component를 찾아주는 역할
1. @ComponentScan이 설정되어 있는 패키지 위치와 그 하위 패키지들을 전부 확인
2. @Component가 설정되어 있는 class들을 전부 찾아서 Bean으로 등록

클래스 이름을 대문자 빼고 ex) memoService 이름으로 Bean 등록해줌

의존성 주입 1 ▶︎ @Autowired

생성자에서 외부에서 주입받을 때는 @Autowired 어노테이션을 달아줘야함

﹡Spring 4.3 버전 이후부터는 @Autowired 생략 가능해짐. 하지만 생성자 선언이 한 개일 때만 생략 가능

여러 방법의 의존성 주입이 존재하지만, 생성자 주입이 객체의 불변성을 지켜줄 수 있기 때문에 생성자로 DI하는 것이 좋음
하지만, 때에 따라서 이미 만들어져 있더라도 주입하는 구현체 변경이 필요한 경우에는 method로 주입을 하는 상황이 발생할 수 있음
필드 주입의 경우 접근 제어자가 private이어서 외부에서 접근할 수 없어도 @Autowired 어노테이션을 달면 접근 가능함(추천 X)
‼️ Autowired를 적용하려면 IoC Container에 의해서 관리되는 Bean class에서만 가능함

의존성 주입 2 ▶︎ Lombok의 @RequiredArgsConstructor 사용

@RequiredArgsConstructor 어노테이션은 final을 생성자로 사용함

의존성 주입 2 ▶︎ 수동으로 주입(ApplicationContext)

ApplicationContext는 BeanFactory 등등의 class들을 상속받아서 기능을 확장한 Container

BeanFactory는 Bean의 생성, 관계 설정 등의 제어를 담당하는 IoC 객체

public MemoService(ApplicationContext context) {
    // 방법 1. Bean의 이름으로 가져오기
    MemoRepository memoRepository = (MemoRepository) context.getBean("memoRepository");
    this.memoRepository = memoRepository;

    // 방법 2. Bean 클래스 형식으로 가져오기
    MemoRepository memoRepository = context.getBean(MemoRepository.class);
    this.memoRepository = memoRepository;
}

‼️ Bean 등록 순서
1. Spring이 Run 될 때, @ComponentScan이 @Component 찾아서 Bean 등록
2. 등록한 후 @Autowired가 달려있는 의존성 주입(DI)가 필요한 곳들에 Bean을 주입해 객체 생성됨

3 Layer Annotation

3 Layer Annotation은 @Controller, @Service, @Repository, @RestController라는 Annotaion이 존재함

Controller, Service, Repository 역할로 구분이 되는 class들을 Bean으로 등록을 할 때, 그 해당 Bean class의 역할을 명확하게 표현하기 위해 사용

위에@Component 어노테이션 존재함

Controller는 내부에서 DispatcherServlet이 Handler Mapping을 통해서 어떤 Controller인지 찾은 후 method 호출할 때 사용함 → 즉, 내부에서 사용하고 있음

'백엔드 > spring&springboot' 카테고리의 다른 글

[내일배움캠프_Spring Boot 입문주차] Spring Data JPA (0)	2026.06.26
[내일배움캠프_Spring Boot 입문주차] JPA CORE (1)	2026.06.25
[내일배움캠프_Spring Boot 입문주차] 3 Layer Architecture (0)	2026.06.25
[내일배움캠프_Spring Boot 입문주차] Database와 SQL (0)	2026.06.24
[내일배움캠프_Spring Boot 입문주차] 메모장 프로젝트 만들기 (0)	2026.06.24

차곡차곡🐿️

[내일배움캠프_Spring Boot 입문주차] IoC와 DI

IoC(제어의 역전), DI(의존성 주입) 이해하기

Spring의 IoC와 DI

의존성

주입

제어의 역전(IoC)

메모장 프로젝트의 IoC와 DI

문제점 1) 객체 생성 중복 코드 존재

문제점 2) 강한 결합 존재

IoC Container와 Bean

Spring IoC 컨테이너

Spring Bean 등록과 의존성 주입

3 Layer Annotation

'백엔드 > spring&springboot' 카테고리의 다른 글

티스토리툴바

[내일배움캠프_Spring Boot 입문주차] IoC와 DI

IoC(제어의 역전), DI(의존성 주입) 이해하기

Spring의 IoC와 DI

의존성

주입

제어의 역전(IoC)

메모장 프로젝트의 IoC와 DI

문제점 1) 객체 생성 중복 코드 존재

문제점 2) 강한 결합 존재

IoC Container와 Bean

Spring IoC 컨테이너

Spring Bean 등록과 의존성 주입

3 Layer Annotation

'백엔드 > spring&springboot' 카테고리의 다른 글

관련글

티스토리툴바