DI(의존성 주입) 생성자 주입는 왜 필요한가

DI는 왜 필요한 것인가
생상자 주입이라는 말은 Spirng을 하면서 수없이 들어보았다. 그렇다면 생성자 주입은 왜 필요한 것일까?

배경

MemberRepository의 인터페이스가 있고 이것의 구현체 MemoryMemberRepository가 있다.

그리고 MemberRepository를 사용하는 MemberService가 있다.

MemberService와 MemberRepository를 연결해보자

MemberService

public class MemberService {
    private final MemberRepository memberRepository = new MemoryMemberRepository();

    ...
}

위와 같이 Injection을 하면 문제는? 외부에서 주입하는 방식으로 할수가 없다. 외부에서 주입하지않고 사용할시 문제점은 무엇일까

문제점1 - DI의 필요성

1. 유지보수에 좋지않다

만약 MemoryMemberRepository기반으로 저장소를 관리하다가 AWS 기반으로 바꾸면 AWSMemberRepository와 의존관계 있는 클라이언트 객체(ex. MemberService)의 코드를 모두 바꿔야하는 불편함이 있다

public class MemberService {
    //private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final MemberRepository memberRepository = new AWSMemberRepository();

    ...
}

2. 테스트 클래스와 같이 다른 외부 클래스에서 클라이언트객체를 사용하는 경우

MemberService를 테스트를 하기위해 Test클래스를 만들어 테스트해본다 가정하자

외부 : MemberServiceTest

class MemberServiceTest{
	MemberService memberService = new MemberService();
	MemoryMemberRepository memoryRepository = new MemoryMemberRepository();

	@AfterEach
  public void afterEach(){
      memberRepository.clearStore(); //이부분때문에 memoryRepository가 필요
  }

	... 
	void 회원가입() {
	...
	...
  }
}

• MemberService에서 주입된 MemberRepository와 MemberServiceTest에서 사용하는 MemberRepository가 다른 인스턴스가 2개라는 문제가 생긴다
• 즉, new MemoryMemberRepository() 가 두번 이루어졌다는 뜻
• DB가 로컬 메모리라고 치면 Repository에 있는 DB는 서로 다른 저장공간으로 서로 다른 두개의 DB가 생겨버린다
  • MemoryMemberRepository객체가 2개(이하 A, B) 생성되었고 MemoryMemberRepository 내 store 변수에 static 키워드가 없다는 것을 전제
  • A에 Member(id:1, name:foo) 엔티티를 저장
  • B에 Member(id:100, name:bar) 엔티티를 저장
  • 위와 같은 상황이라면 저장공간이 별도로 분리되어 있기 때문에 name을 foo로 가지는 데이터를 불러오려면 무조건 A에 접근해야 하는 상황이 발생
  • 만약 static 키워드로 생성된 store 변수였다면 A, B객체는 store 변수를 공유하기 때문에 A, B 어디서든지 name을 foo로 가지는 데이터를 불러올 수 있음

이러한 문제를 해결하기위해 외부에서 주입하는 방식으로 바꾸어야한다

해결1 :외부에서 주입

MemberService

public class MemberService {
	
	//private final MemberRepository memberRepository = new MemoryMemberRepository();
  private final MemberRepository memberRepository;

  public MemberService(MemberRepository memberRepository) {
      this.memberRepository = memberRepository;
  }
}

MemberServiceTest

class MemberServiceTest {

  MemberService memberService;
  MemoryMemberRepository memberRepository;

  @BeforeEach
  public void beforeEach(){
      memberRepository = new MemoryMemberRepository();
      memberService = new MemberService(memberRepository);
  }

}

이런식으로 외부에서 두개(MemberRepository, MemberService)를 연결시켜주어 사용할수 있다.

하지만 이것도 다른 문제가 있다.

문제점2 - 싱글톤

Controller(=외부)에 Service를 DI를 하려한다.

@Controller
public class MemberController {

  private final MemberRepository memberRepository = new MemoryMemberRepository();
  private final MemberService memberService = new MemberService(memberRepository);

}

이런 방식으로 DI를 해도 되지만 이렇게 하면 OrderController라든가 다른 Controller들이 `MemberService를 사용하면 여러개의 인스턴스가 생기는 문제가 있다. → 하나를 생성해서 같이 공용으로 쓰자 → 스프링 컨테이너에 빈으로 등록하자

해결2: 스프링 빈으로 등록

스프링 빈을 등록하는 2가지 방법

• 컴포넌트 스캔과 자동 의존관계 설정 → @Component
• 자바 코드로 직접 스프링 빈 등록하기 → SpringConfig(@Configuration)

---

A. 컴포넌트 스캔과 자동 의존관계 설정

MemberController

@Controller
public class MemberController {
    private final MemberService memberService;

    @Autowired
    public MemberController(MemberService memberService) {
        this.memberService = memberService;
    }
}

MemberService

@Service
public class MemberService {
	private final MemberRepository memberRepository;
    
  @Autowired
  public MemberService(MemberRepository memberRepository) {
      this.memberRepository = memberRepository;
  }
	...
}

MemberRepository

@Repository
public class MemoryMemberRepository implements MemberRepository{

    private static Map<Long, Member> store = new HashMap<>();
    private static long sequence = 0L;
		...
}

• @Controller와 @Service는 @Component가 포함되어있다
• @Component는 스프링컨테이너에 스프링빈으로 등록해준다
• @Autowired를 통해 서로 주입된다

@Autowired는 Bean으로 등록된 클래스만 가능하다

B. 자바 코드로 직접 스프링 빈 등록하기

---

비교를 위해 기존 Componet 등록 삭제하자

MemberService

//@Service
public class MemberService {
    //private final MemberRepository memberRepository = new MemoryMemberRepository();
    private final MemberRepository memberRepository;
c
    //@Autowired
    public MemberService(MemberRepository memberRepository) {
        this.memberRepository = memberRepository;
    }

MemberRepository

//@Repository
public class MemoryMemberRepository implements MemberRepository{
	...
}

---

직접 빈 등록

SpringConfig

@Configuration
public class SpringConfig {
    @Bean
    public MemberService memberService() {
        return new MemberService(memberRepository());
    }
    @Bean
    public MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }
}

두가지 방식 중 무엇을 선택해야할까

• 실무에서는 주로 정형화된 컨트롤러, 서비스, 리포지토리 같은 코드는 컴포넌트 스캔을 사용한다.
• 그리고 정형화 되지 않거나, 상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록
• 다형성을 이용하는 경우 예를들면 위에서 만든 MemoryMemberRepository와 같이 언제든 바꿀수 있는경우 설정을 통해 스프링 빈 등록이 좋다

스프링 빈등록 부분을 보면 @Configuration과 @Bean가 있다. 이 애노테이션은 무슨 역할을 할까
다음 포스팅에서 알아보자

Spring

👉 JWT + Spring Security + Spring Cloud = MSA 3. ApiGateway 2023.01.11

👉 JWT + Spring Security + Spring Cloud = MSA 2. Spring Security 2022.12.14

👉 JWT + Spring Security + Spring Cloud = MSA 1. 환경세팅 2022.11.14

👉 Spring Security - Role (단일 권한, 복합 권한) 2022.11.10

👉 Spring Security를 이용한 로그인 처리 2022.10.31

👉 REST API - Exception을 통하여 HTTP Response 처리 2022.10.10

👉 Assert을 커스텀(custom)하여 파라미터 검증 2022.10.10

👉 애노테이션을 사용한 파라미터 검증 2022.10.09

👉 제네릭 기본 및 응용 2022.10.07

👉 DataSource와 ConnectionPool 2022.07.11

👉 JSP - EL 표현식에서 언제 오류 페이지가 나타날까 2022.05.27

👉 IoC와 DI컨테이너 2022.05.26

👉 DI(의존성 주입) 생성자 주입는 왜 필요한가 2022.05.25

👉 스프링을 왜 사용하는가 2022.05.23

👉 Servlet 2022.02.07

Java

👉 JWT + Spring Security + Spring Cloud = MSA 3. ApiGateway 2023.01.11

👉 JWT + Spring Security + Spring Cloud = MSA 2. Spring Security 2022.12.14

👉 JWT + Spring Security + Spring Cloud = MSA 1. 환경세팅 2022.11.14

👉 Spring Security - Role (단일 권한, 복합 권한) 2022.11.10

👉 Spring Security를 이용한 로그인 처리 2022.10.31

👉 REST API - Exception을 통하여 HTTP Response 처리 2022.10.10

👉 Assert을 커스텀(custom)하여 파라미터 검증 2022.10.10

👉 애노테이션을 사용한 파라미터 검증 2022.10.09

👉 제네릭 기본 및 응용 2022.10.07

👉 Refactoring 2022.08.16

👉 JSP - EL 표현식에서 언제 오류 페이지가 나타날까 2022.05.27

👉 IoC와 DI컨테이너 2022.05.26

👉 DI(의존성 주입) 생성자 주입는 왜 필요한가 2022.05.25

👉 스프링을 왜 사용하는가 2022.05.23

👉 Servlet 2022.02.07