[SpringBoot] 스프링 Bean과 의존성 주입(Dependency Injection) feat: 컴포넌트 스캔과 싱글톤 패턴, 제어의 역전

Bean

스프링 컨테이너에 의해 관리되는 재사용 가능한 소프트웨어 컴포넌트(component)로, 스프링 컨테이너가 관리하는 자바 객체를 뜻한다. 

의존성 주입이란?

보통 스프링에서는 controller 클래스에서 요청을 받고, 해당 요청에 대한 비즈니스 로직에 대한 처리는 service 클래스에서 구현하고, 이 비즈니스 로직에서 필요한 데이터 접근에는 repository 클래스에서 처리를 한다. 이 경우 controller는 service에 의존하고, service는 repository에 의존하는 형식으로 일반적으로 스프링부트 프로젝트가 구성된다. 

예를 들어,

public class MemberController {

    private final MemberService memberService;
    
    public MemberController() {
    	this.memberService = new MemberService();
    }
}

이 코드에서 MemberController는 MemberService에 의존하고 있다. 이 코드의 문제점은 무엇일까?

- 두 "클래스"가 강하게 결합되어 있다.

- 객체들 간의 관계가 아니라 클래스 간의 관계가 맺어져있다.

 

이 문제를 어떻게 해결할 수 있을까? 

외부에서 MemberService를 주입(Injection)받아야 한다.

public class MemberController {

    private final MemberService memberService;

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

 

와 같이 memberService객체를 받아 MemberController 객체로 주입한다. 

따라서 우리는 Spring이라는 DI(Dependency Injection, 의존성 주입) 컨테이너를 필요로 한다. 애플리케이션의 실행 시점에 필요한 객체=빈을 생성해야 하며, 의존성이 있는 두 객체를 연결하기 위한 한 객체를 다른 객체로 주입시켜야 한다. 

 

스프링에선 생성자에 @Autowired가 존재하면,스프링이 연관된 객체를 스프링 컨테이너에서 찾아서 넣어주는 방식으로 의존성 주입을 한다. 바로 위의 코드에선 개발자가 직접 의존성 주입을 해준 것이고, @Autowired를 사용하면 스프링에서 자동으로 객체의 의존관계를 외부에서 넣어준다. 하지만 이 의존성을 넣어주기 위한 객체도 스프링 컨테이너에 등록되어있어야 의존성을 넣어줄 수 있기 때문에, 

 @Controller
 public class MemberController {
     private final MemberService memberService;
     @Autowired
     public MemberController(MemberService memberService) {
         this.memberService = memberService;
     }
}

MemberService 클래스도 빈으로 등록, MemberController도 물론 빈으로 등록되어 있어야 한다. 스프링은 스프링 컨테이너에 등록된 빈=객체들을 관리하기 때문이다. 또한 이렇게 스프링이 자동으로 객체를 생성하고 객체들의 의존 관계까지 설정해주는 개념은 "제어의 역전(Inversion of Control, IoC)"이라고도 한다. 개발자가 객체의 관계를 관리하고, 객체를 관리하는 것이 아닌 스프링 컨테이너가 관리해줌으로써 제어가 역전되었다는 것을 의미한다.

의존성 주입 방법 3가지

1. 필드 주입(권장 x)

@Controller
public class MemberController {

    @Autowired MemberService memberService;

}

코드가 간결하지만, 외부에서 변경이 불가능해서 테스트하기 힘들다는 치명적인 단점 존재.

DI 프레임워크가 없으면 어떤 것도 불가능

2. setter 주입

@Controller
public class MemberController {

    private MemberService memberService;

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

}

단점: public으로 선언하여 외부 클래스에서 접근하고 변경 가능. 의존 관계는 프로젝트 시작부터 끝까지 불변하여야 맞다. 나중에 바꿀일이 없도록 설계하여야 하기 때문에 권장되지 않는다.

3. 생성자 주입(권장)

@Controller
public class MemberController {

    private MemberService memberService;

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

}

장점: 생성하는 시점에만 생성이 되고, 이후 변경 불가능.

• 불변, 필수인 의존 관계에 사용된다.
• 필드를 final로 선언하여 수정 불가능하게 할 수 있다.  -> 생성자에서 혹시라도 값이 설정되지 않는 오류를  "컴파일 시점"에 막아준다. 
• 위에서 말했듯이 대부분의 의존관계 주입은 한 번 일어나면 애플리케이션의 종료 시점까지 의존관계를 변경할 일이 없어야 한다. -> 불변해야한다. 그렇기 때문에 스프링에서는 이 의존관계 주입을 권장하는 것.!!
• *참고: 생성자 주입을 통해 의존관계를 주입할 경우 생성자가 클래스에 한개만 있다면 스프링에서 자동으로 @Autowired 어노테이션을 붙여준다. 
• 또한, 테스트시 원하는 객체를 바꿔 끼워가며 테스트 가능

@Test
void createOrder() {
    MemoryMemberRepository memberRepository = new MemoryMemberRepository();
    memberRepository.save(new Member(1L, "name", Grade.VIP));

    OrderServiceImpl orderService = new OrderServiceImpl(memberRepository, new FixDiscountPolicy());
    Order order = orderService.createOrder(1L, "itemA", 10000);
    Assertions.assertThat(order.getDiscountPrice()).isEqualTo(1000);
}

생성자 주입을 더 간결하고 깔끔하게 하는 방법에는 뭐가 있을까?

@Component
@RequiredArgsConstructor    // 생성자 자동 생성
public class OrderServiceImpl implements OrderService {

	private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

    @Override
    public Order createOrder(Long memberId, String itemName, int itemPrice) {
        Member member = memberRepository.findById(memberId);
        int discountPrice = discountPolicy.discount(member, itemPrice);

        return new Order(memberId, itemName, itemPrice, discountPrice);
    }

    public MemberRepository getMemberRepository() {
        return memberRepository;
    }
}

와 같이 사용 가능하면 매우 간결하게 코드를 작성하고, 생성자 주입을 통한 의존관계 주입이 가능해진다.

@RequiredArgsConstructor

어노테이션을 사용하여 생성자를 간편하게 생성할 수 있다. "final이 붙은 필드"를 모아서 생성자를 자동으로 만들어준다. 

위 코드의 경우 생성자는 1개이니 자동으로  @Autowired가 된다. 

최근에는 생성자를 1개 두고, @Autowired를 생략하는 방법을 주로 사용한다. 위 어노테이션까지 사용하면, 기능을 모두 제공하며 코드를 깔끔하게 작성할 수 있어 이렇게 작성하는 것이 권장된다. 

어떻게 스프링 컨테이너에 클래스들을 빈으로 등록할 수 있을까?

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

우선 위의 코드에선 @Controller어노테이션을 통해 MemberController를 스프링 컨테이너에 빈으로 등록할 수 있었다.

보통 @Component어노테이션을 통해 스프링 컨테이너에 빈을 등록해 주는데 어떻게 @Controller 어노테이션을 통해 빈이 등록될 수 있었던 걸까?

 

@Controller 어노테이션에 들어가 보면, 이렇게 컴포넌트 어노테이션이 명시되어 있다. @Service, @Repository 어노테이션도 마찬가지이다. 이렇게 스프링은 "컴포넌트 스캔"을 통해 자동으로 객체들을 빈으로 등록하고, 의존관계를 설정한다. 

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

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

컴포넌트가 포함되어있는 어노테이션을 삭제하고 등록해주어야 한다. 

 

스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본으로 싱글톤으로 등록한다.

* @Bean과 @Component의 차이점??

갑자기 그러면 @Bean과 @Component는 무엇일까? 라는 생각이 들었다. 그래서 찾아보니 김영한님이 친절하게 답변해주셨다. 

• @Bean은 수동으로 스프링 컨테이너에 스프링 빈을 등록하는 것
• @Component는 자동으로 스프링 컨테이너에 스프링 빈을 등록하는 기능. 

추가적으로 바로 위 코드의 @Configuration도 내부에 @Component가 붙어있어, 설정 정보 자체도 스프링 빈으로 자동 등록 된다. 

싱글톤 패턴(Singleton Pattern)이란?

객체의 인스턴스가 오직 1개만 생성되는 패턴으로, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이며 이후에 호출된 생성자는 최초의 생성자가 객체를 리턴하는 것. (=공유하는 것.) 예를 들어 OrderService에서 MemberRepository가 필요하여 의존 관계가 설정되어있어도, MemberService에서 사용하고 있는 MemberRepository객체를 둘이 공유하여 사용하는 것이다.(새로운 MemberRepository 객체 생성 되는 것 x)

싱글톤 패턴을 사용하는 이유

서버의 성능을 올릴 수 있다. 만약 싱글톤으로 빈을 생성하지 않고 요청 마다 생성한다고 가정해보자.

요청 한개당 5개의 객체를 생성하고 초당 500개의 요청이 올 경우 객체는 2500개를 생성하여 서버의 성능이 저하된다.

하지만 싱글톤으로 bean을 생성하게 되면, was시작시에만 생성이 되고, 요청이 계속 들어오더라도 bean은 더이상 생성되지 않기 때문에 성능을 높일 수 있다.

References

https://mangkyu.tistory.com/150

[Spring] 의존성 주입(Dependency Injection, DI)이란? 및 Spring이 의존성 주입을 지원하는 이유

인프런 - 스프링강의(김영한님)