Program Artist를 꿈꾸는 Blog

스프링 컨테이너의 기본적인 스프링 빈 조회 방법

• ac.getBean(빈이름, 타입)
• ac.getBean(타입)
• 조회 대상 스프링 빈이 없으면 오류 발생
  • NoSuchBeanDefinitionException: No bean named ‘xxxx’ available

예제 코드

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        System.out.println("memberService = " + memberService);
        System.out.println("memberService.getClass() = " + memberService.getClass());
    }
}

• 출력 결과
  • memberService = hello.core.member.MemberServiceImpl@37c7595
  • memberService.getClass() = class hello.core.member.MemberServiceImpl

빈 이름으로 조회 검증

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

• memberService는 MemberServiceImpl의 인스턴스
  • AppConfig에서 memberService 메소드는 MemberServiceImpl 객체를 new 하여 리턴
  • return new MemberServiceImpl(*memberRepository*());

이름 없이 타입으로만 조회 추가

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

• 테스트 통과

구체 타입으로 조회 추가

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2() {
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

• 빈 이름으로 조회 시 인터페이스인 MemberService가 아닌, 구체 클래스인 MemberServiceImpl로 타입을 넣어도 정상 조회 가능
• AppConfig에서 memberService의 반환 타입이 MemberService라도 MemberServiceImpl로 타입을 넣을 수 있음
• 하지만 이 같이 구체 클래스를 타입으로 넣는 것은 좋지 않은 방법(역할과 구현의 분리, 역할에 의존)
  • 유연성이 떨어지지만, 가끔 필요할 때가 있음

빈 이름으로 조회X 추가

package hello.core.beanfind;

import hello.core.AppConfig;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.NoSuchBeanDefinitionException;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

import static org.assertj.core.api.Assertions.*;
import static org.junit.jupiter.api.Assertions.*;

public class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2() {
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

    @Test
    @DisplayName("빈 이름으로 조회X")
    void findBeanByNameX() {
        //  ac.getBean("xxxxx", MemberService.class);

        // NoSuchBeanDefinitionException이 발생해야 테스트 성공
        assertThrows(NoSuchBeanDefinitionException.class,
                () -> ac.getBean("xxxxx", MemberService.class));
    }
}

• NoSuchBeanDefinitionException이 발생해야 테스트 성공
• assertThrows는 static import 한 상태
  • org.junit.jupiter.api.Assertions을 사용(assertThat은 assertj)
  • import static org.junit.jupiter.api.Assertions.*;

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.

테스트 코드 작성

• hello.core.beanfind 패키지에 ApplicationContextInfoTest 클래스 생성

package hello.core.beanfind;

import hello.core.AppConfig;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.config.BeanDefinition;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class ApplicationContextInfoTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + " object = " + bean);

        }
    }

    @Test
    @DisplayName("애플리케이션 빈 출력하기")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            // Role ROLE_APPLICATION: 직접 등록한 애플리케이션 빈
            // Role ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈
            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName + " object = " + bean);
            }
        }
    }
}

설명

• 모든 빈 출력하기
  • 스프링에 등록된 모든 빈 정보 출력
  • ac.getBeanDefinitionNames()
    • 스프링에 등록된 모든 빈 이름 조회
  • ac.getBean()
    • 빈 이름으로 빈 객체(인스턴스)를 조회
• 애플리케이션 빈 출력
  • 스프링 내부에서 사용하는 빈은 제외하고, 등록한 빈만 출력
  • 스프링이 내부에서 사용하는 빈은 getRole()로 구분 가능
    • ROLE_APPLICATION: 일반적으로 사용자가 정의한 빈
    • ROLE_INFRASTRUCTURE: 스프링이 내부에서 사용하는 빈

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.

스프링 컨테이너 생성

• 스프링 컨테이너가 생성되는 과정

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext를 스프링 컨테이너라고 함
• ApplicationContext는 인터페이스
  • 이를 구현한 것 중 하나가 AnnotationConfigApplicationContext임
• 스프링 컨테이너는 XML 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로도 만들 수 있음
  • 요즘에는 XML 기반은 잘 사용하지 않음
  • 애노테이션 기반이 편리하기 때문에 대부분 애노테이션 기반 방식을 사용
• 직전에 AppConfig를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것
• 참고: 더 정확히는 스프링 컨테이너를 부를 때 BeanFactory, ApplicationContext 로 구분해서 이야기한다.
  • BeanFactory 를 직접 사용하는 경우는 거의 없으므로 일반적으로 ApplicationContext 를 스프링 컨테이너라 한다.

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성

• new AnnotationConfigApplicationContext(AppConfig.class)
• 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야 함
• 여기서는 AppConfig.class를 구성 정보로 전달
• 스프링 빈 저장소의 key는 빈 이름, value는 빈 객체가 됨

2. 스프링 빈 등록

• 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용하여 스프링 빈을 등록함
• 메소드 이름을 빈 이름으로, return으로 반환하는 객체를 빈 객체로 등록
  • 4개의 new로 생성한 인스턴스 객체가 등록이 됨
  • 이를 스프링 빈이라 함
• 빈 이름
  • 빈 이름은 보통 메소드 이름을 사용
  • 빈 이름을 직접 부여할 수도 있음
    • @Bean(name="이름")
  • 빈 이름은 항상 다른 이름을 부여해야 함
    • 같은 이름을 부여하면, 다른 빈이 무시되거나 기존 빈을 덮어버리거나 설정에 따라 오류가 발생

3. 스프링 빈 의존관계 설정 - 준비

• 오른쪽의 초록색 원들이 스프링 빈

4. 스프링 빈 의존관계 설정 - 완료

• 스프링 컨테이너는 설정 정보를 참고해서 의존관계를 주입(DI)
• 단순히 자바 코드를 호출하는 것 같지만, 차이가 있음
  • 이 차이는 뒤의 싱글톤 컨테이너에서 설명
• 참고
  • 스프링은 빈을 생성하고, 의존관계를 주입하는 단계가 나누어져 있음
    • 그런데 이렇게 자바 코드로 스프링빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리됨
  • 여기서는 이해를 돕기 위해 개념적으로 나누어 설명
    • 자세한 내용은 의존관계 자동 주입에서 다시 설명

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.

AppConfig 스프링 기반으로 변경

package hello.core;

import hello.core.discount.DiscountPolicy;
import hello.core.discount.FixDiscountPolicy;
import hello.core.discount.RateDiscountPolicy;
import hello.core.member.MemberRepository;
import hello.core.member.MemberService;
import hello.core.member.MemberServiceImpl;
import hello.core.member.MemoryMemberRepository;
import hello.core.order.OrderService;
import hello.core.order.OrderServiceImpl;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class AppConfig {

    @Bean
    public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

    @Bean
    public static MemberRepository memberRepository() {
        return new MemoryMemberRepository();
    }

    @Bean
    public OrderService orderService() {
        return new OrderServiceImpl(memberRepository(), discountPolicy());
    }

    @Bean
    public DiscountPolicy discountPolicy() {
//        return new FixDiscountPolicy();
        return new RateDiscountPolicy();
    }
}

• AppConfig에 설정을 구성한다는 뜻의 @Configuration 을 붙여준다.
• 각 메서드에 @Bean 을 붙여준다. 이렇게 하면 스프링 컨테이너에 스프링 빈으로 등록한다.

MemberApp에 스프링 컨테이너 적용

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class MemberApp {

    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

        Member member = new Member(1L, "memberA", Grade.VIP);
        memberService.join(member);

        Member findMember = memberService.findMember(1L);
        System.out.println("new member = " + member);
        System.out.println("findMember = " + findMember);
    }
}

• 주석 처리된 부분에 스프링을 적용하여 변경
• ApplicationContext는 컨테이너 기능을 하는 스프링 컨테이너
• AppConfig에서 @Bean으로 등록한 빈들은 getBean을 통해 가져올 수 있음

OrderApp에 스프링 컨테이너 적용

package hello.core;

import hello.core.member.Grade;
import hello.core.member.Member;
import hello.core.member.MemberService;
import hello.core.order.Order;
import hello.core.order.OrderService;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

public class OrderApp {

    public static void main(String[] args) {
//        AppConfig appConfig = new AppConfig();
//        MemberService memberService = appConfig.memberService();
//        OrderService orderService = appConfig.orderService();
        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);
        OrderService orderService = applicationContext.getBean("orderService", OrderService.class);

        Long memberId = 1L;
        Member member = new Member(memberId, "memberA", Grade.VIP);
        memberService.join(member);

        Order order = orderService.createOrder(memberId, "itemA", 10000);

        System.out.println("order = " + order.toString());
    }
}

• 주석 처리된 부분에 스프링을 적용하여 변경
• ApplicationContext는 컨테이너 기능을 하는 스프링 컨테이너
• AppConfig에서 @Bean으로 등록한 빈들은 getBean을 통해 가져올 수 있음

스프링 컨테이너

• ApplicationContext 를 스프링 컨테이너라 함
• 기존에는 개발자가 AppConfig 를 사용해서 직접 객체를 생성하고 DI를 했지만,
  • 이제부터는 스프링 컨테이너를 통해서 사용한다.
• 스프링 컨테이너는 @Configuration 이 붙은 AppConfig 를 설정(구성) 정보로 사용한다. 여기서 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다.
  • 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.
• 스프링 빈은 @Bean 이 붙은 메소드의 명을 스프링 빈의 이름으로 사용한다. (memberService, orderService)
  • @Bean(name = “이름”)으로 스프링 빈의 이름을 직접 지정할 수도 있다.
    • 웬만하면 디폴트(메소드 명)를 따르는게 좋다.
  • 이전에는 개발자가 필요한 객체를 AppConfig 를 사용해서 직접 조회했지만, 이제부터는 스프링 컨테이너를 통해서 필요한 스프링 빈(객체)를 찾아야 한다.
  • 스프링 빈은 applicationContext.getBean() 메서드를 사용해서 찾을 수 있다.
• 기존에는 개발자가 직접 자바코드로 모든 것을 했다면 이제부터는 스프링 컨테이너에 객체를 스프링 빈으로 등록하고, 스프링 컨테이너에서 스프링 빈을 찾아서 사용하도록 변경되었다.
• 코드가 약간 더 복잡해진 것 같은데, 스프링 컨테이너를 사용하면 어떤 장점이 있을까?
  • 앞으로 진행하면서 알게 됨

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.

제어의 역전 IoC(Inversion of Control)

• 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.
  • 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.
• 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다.
  • 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다.
• 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다.
  • 심지어 OrderServiceImpl도 AppConfig가 생성한다.
  • 그리고 AppConfig는 OrderServiceImpl이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 도 있다.
  • 이러한 정보 없이 OrderServiceImpl은 자신의 로직을 실행한다.

프레임워크 vs 라이브러리

• 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
• 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.
  • ex) Java 객체를 XML, JSON로 바꿔주는 라이브러리

의존관계 주입 DI(Dependency Injection)

• OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존한다.
  • 실제 어떤 구현 객체가 사용될지는 모른다.
• 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 한다.

정적인 클래스 의존관계

• 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다.
• 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다.

클래스 다이어그램

• 클래스 다이어그램을 보자 OrderServiceImpl은 MemberRepository , DiscountPolicy 에 의존한다는 것을 알 수 있다.
  • OrderServiceImpl은 DiscountPolicy만 보고 있음
• 그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl에 주입 될지 알 수 없다.

동적인 객체 인스턴스 의존 관계

• 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

객체 다이어그램

• 애플리케이션 **실행 시점(런타임)**에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
• 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.
• 또는 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.

제어의 역전 IoC(Inversion of Control)

• 기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성하고, 연결하고, 실행했다.
  • 구현 객체가 프로그램의 제어 흐름을 스스로 조종했다. 개발자 입장에서는 자연스러운 흐름이다.
• 반면에 AppConfig가 등장한 이후에 구현 객체는 자신의 로직을 실행하는 역할만 담당한다. 프로그램의 제어 흐름은 이제 AppConfig가 가져간다.
  • 예를 들어서 OrderServiceImpl 은 필요한 인터페이스들을 호출하지만 어떤 구현 객체들이 실행될지 모른다.
• 프로그램에 대한 제어 흐름에 대한 권한은 모두 AppConfig가 가지고 있다.
  • 심지어 OrderServiceImpl도 AppConfig가 생성한다.
  • 그리고 AppConfig는 OrderServiceImpl이 아닌 OrderService 인터페이스의 다른 구현 객체를 생성하고 실행할 수 도 있다.
  • 이러한 정보 없이 OrderServiceImpl은 자신의 로직을 실행한다.

프레임워크 vs 라이브러리

• 프레임워크가 내가 작성한 코드를 제어하고, 대신 실행하면 그것은 프레임워크가 맞다. (JUnit)
• 반면에 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 그것은 프레임워크가 아니라 라이브러리다.
  • ex) Java 객체를 XML, JSON로 바꿔주는 라이브러리

의존관계 주입 DI(Dependency Injection)

• OrderServiceImpl 은 DiscountPolicy 인터페이스에 의존한다.
  • 실제 어떤 구현 객체가 사용될지는 모른다.
• 의존관계는 정적인 클래스 의존 관계와, 실행 시점에 결정되는 동적인 객체(인스턴스) 의존 관계 둘을 분리해서 생각해야 한다.

정적인 클래스 의존관계

• 클래스가 사용하는 import 코드만 보고 의존관계를 쉽게 판단할 수 있다.
• 정적인 의존관계는 애플리케이션을 실행하지 않아도 분석할 수 있다.

클래스 다이어그램

• 클래스 다이어그램에서 OrderServiceImpl은 MemberRepository , DiscountPolicy에 의존한다는 것을 알 수 있다.
  • OrderServiceImpl은 DiscountPolicy만 보고 있음
• 그런데 이러한 클래스 의존관계 만으로는 실제 어떤 객체가 OrderServiceImpl에 주입 될지 알 수 없다.

동적인 객체 인스턴스 의존 관계

• 애플리케이션 실행 시점에 실제 생성된 객체 인스턴스의 참조가 연결된 의존 관계다.

객체 다이어그램

• 애플리케이션 실행 시점(런타임)에 외부에서 실제 구현 객체를 생성하고 클라이언트에 전달해서 클라이언트와 서버의 실제 의존관계가 연결 되는 것을 의존관계 주입이라 한다.
• 객체 인스턴스를 생성하고, 그 참조값을 전달해서 연결된다.
• 의존관계 주입을 사용하면 클라이언트 코드를 변경하지 않고, 클라이언트가 호출하는 대상의 타입 인스턴스를 변경할 수 있다.
• 의존관계 주입을 사용하면 정적인 클래스 의존관계를 변경하지 않고, 동적인 객체 인스턴스 의존관계를 쉽게 변경할 수 있다.

IoC 컨테이너, DI 컨테이너

• AppConfig 처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC 컨테이너 또는 DI 컨테이너라 한다.
• 의존관계 주입에 초점을 맞추어 최근에는 주로 DI 컨테이너라 한다.
• 또는 어샘블러, 오브젝트 팩토리 등으로 불리기도 한다.

※ 본 게시글은 인프런의 스프링 핵심 원리 - 기본편(김영한)을 수강하고 정리한 내용입니다.