0m1n's Develog

싱글톤 스코프의 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다. 반면 프로토타입 스코프를 스프링 컨테이너에 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다. 스프링 컨테이너는 프로토타입 빈을 생성하고, 의존관계 주입, 초기화까지만 처리한다. 클라이언트에 빈을 반환하고, 이후 스프링 컨테이너는 프로토타입 빈을 관리하지 않는다. 따라서 프로토타입 빈을 관리할 책임은 빈을 받은 클라이언트에 있다. 그래서 @PreDestory 같은 종료 메서드가 호출되지 않는다. 프로토타입 스코프 빈을 조회하는 prototypeBeanFind()를 실행하면 아래와 같은 결과가 나온다. @Scope("prototype") find prototypeBean1 PrototypeBean..

- 편리한 자동 기능을 기본으로 사용하자! 스프링이 나온 후 점점 자동을 선호하는 추세다. @Component 뿐만 아니라 @Controller, @Service, @Repository 처럼 계층에 맞춰 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. (최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 빈들도 조건에 맞으면 자동으로 등록하도록 설계되어있음) 자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있으므로 사용하는게 좋다. - 그럼 수동 빈 등록은 언제 사용하지? 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다. 업무 로직 빈 : 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등 / 보통 비즈니스 ..

스프링에서 조회 대상 빈이 2개 이상일 때 해결할 수 있는 방법을 알아보자. @Autowired 필드명 @Qailifier → @Qailifier끼리 매칭 → 빈 이름 매칭 @Primary 사용 1. @Autowired 필드 명 매칭 @Autowired 는 타입 매칭을 시도하고, 이때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭 타입 매칭 타입 매칭의 결과가 2개 이상일 때 필드 명, 파라미터 명으로 빈 이름 매칭 기존 코드 @Autowired private DiscountPolicy discountPolicy; 필드 명을 빈 이름으로 변경 @Autowired private DiscountPolicy rateDiscountPolicy; 2. @Qualifier 사용 @Qualif..

의존관계 주입은 크게 4가지 방법이 있다. 생성자 주입 수정자 주입(setter 주입) 필드 주입 일반 메서드 주입 1. 생성자 주입 지금까지 진행했던 방법 생성자 호출시점에 딱 1번만 호출되는 것이 보장 '불변, 필수' 의존관계에 사용 OrderServiceImpl을 확인해보자. @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discountPolicy; } 생성자를 통해서만 DI가 되며, 누구도 외부에서 수정할 수 없다. 생성자가 딱 1개만 있으면 @Au..

컴포넌트 스캔에서 같은 빈 이름을 등록하게 되는 경우 충돌이 발생할까? 아래와 같이 2가지 상황이 있다고 하자. 자동 빈 등록 vs 자동 빈 등록 수동 빈 등록 vs 자동 빈 등록 1. 자동 빈 등록 vs 자동 빈 등록 역시 충돌이 나며, 에러를 발생시킨다. 2. 수동 빈 등록 vs 자동 빈 등록 헷갈릴 수 있는 부분이다. 테스트를 해보자! AutoAppConfig 파일에 아래와 같이 다른 빈을 등록한다. public class AutoAppConfig { @Bean(name = "memoryMemberRepository") MemberRepository memberRepository(){ return new MemoryMemberRepository(); } } MemoryMemberRepository ..

스프링 컨테이너는 싱글톤 패턴을 적용하지 않아도, 객체 인스턴스를 싱글톤으로 관리한다. (스프링 컨테이너 생성과정에서, 컨테이너는 객체를 하나만 생성해서 관리) 스프링 컨테이너가 싱글톤 컨테이너 역할을 해서 싱글톤 객체를 생성하고 관리한다. 이 기능을 싱글톤 레지스트 라고 한다. 싱글톤 레지스트의 장점은 싱글톤 패턴을 위한 지저분한 코드 필요x DIP, OCP, 테스트, private 생성자로부터 자유롭게 싱글톤 사용 가능 이전의 코드에서 스프링 컨테이너를 사용하는 부분만 바꾸어 테스트를 진행해보자! void springContainer(){ // AppConfig appConfig = new AppConfig(); ApplicationContext ac = new AnnotationConfigAppli..

대부분의 스프링 애플리케이션은 웹 애플리케이션이다. (물론 애플리케이션 개발도 가능) 웹 애플리케이션의 경우 보통 여러 고객이 동시에 요청을 하게 된다! 따라서 요청이 올때마다 객체를 만들게 되는 경우가 발생한다. (아래 AppConfig 에서도 memberService 요청이 들어오면 그 객체를 만들어준다.) @Configuration // 설정 정보 public class AppConfig { @Bean // 클래스 스프링 컨테이너에 등록 public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); // memberService 구현체, 객체 생성 } } 테스트를 진행해보자. AppConfig 파일에서 가..

제어의 역전 IoC(Inversion of Control) 프로그램의 제어 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것 기존 프로그램에서는 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성/연결/실행했다. (이전 예시 코드를 통해 확인할 수 있다.) private final MemberRepository memberRepository = new MemoryMemberRepository(); 그러나 의존성 주입(DI)을 통해 AppConfig에서 프로그램을 제어하고, 구현 객체는 자신의 로직을 실행하는 역할만 담당하게 됐다. public class MemberServiceImpl implements MemberService { // private final MemberRepositor..