<Spring> 스프링 핵심원리 이해 10 - 스프링 빈 스코프(웹 스코프)
웹 스코프이전 포스팅에서 우리는 싱글톤과 프로토타입 스코프에 대해서 공부했다.다시 요약하자면 싱글톤은 스프링 컨테이너의 시작와 끝까지 모두 함께하는 스코프이고 프로토타입의 경우 컨테이너에서는 의존관계주입 그리고 초기화까지만 관리하는 스코프이다. 이번에는 웹 스코프에 대한 포스팅이다. 웹
웹 스코프이전 포스팅에서 우리는 싱글톤과 프로토타입 스코프에 대해서 공부했다.다시 요약하자면 싱글톤은 스프링 컨테이너의 시작와 끝까지 모두 함께하는 스코프이고 프로토타입의 경우 컨테이너에서는 의존관계주입 그리고 초기화까지만 관리하는 스코프이다. 이번에는 웹 스코프에 대한 포스팅이다. 웹
빈 스코프란지금까지 우리는 스프링 빈이 스프링 컨테이너의 시작과 함께 생성되어서 스프링 컨테이너가 종료 될때까지 유지된다고 학습했다.이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. scope란 단어의 뜻 그대로 스프링 빈이 존재할 수 있는
스프링 컨테이너의 생명주기생성->빈 설정->사용->소멸순으로 구성된다.아래와 같은 방식으로 스프링 컨테이너에 대한 라이프사이클 메서드를 사용할 수 있다.AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(); ac.register();//빈 추가로 등록 ac.referesh(
다양한 의존관계 주입 방법의존관계 주입에는 아래와 같이 크게 4가지 방법이 존재한다.아래 네가지 방법이 어떤식으로 의존관계를 주입하는지 알아보자. 생성자 주입수정자 주입(setter 주입)필드 주입일반 메서드 주입생성자 주입이름 그대로 생성자를 통해서 의존관계를 주입받는
컴포넌트 스캔과 의존관계 자동 주입 설정하기지금까지의 과정에선 스프링 빈을 만들 때, 대상이 되는 메서드에 @Bean을 붙여서 AppConfig에 직접 명시하는 방식을 채택했었다.하지만 이러한 방식은 등록해야 할 빈의 수가 수 백개가 될 경우, 실수를
웹 어플리케이션과 싱글톤의 관계여러 고객이 동시에 동일한 서비스를 요청하는 경우통상적으로 서비스를 운영하다보면 위 그림과 같이 동일한 요청이 서로 다른 클라이언트로부터 동시에 들어올 수 있다.요청이 들어오면 객체를 만들어서 메모리를 사용하게 되는데, 만약 동일한
스프링 컨테이너 생성이전 시간에 우리는 ConfigApp 클래스에 스프링 빈을 등록하고 해당 컨테이너가 객체를 찾고 의존성을 연결해주는 과정을 진행했다.스프링 컨테이너의 생성은 아래의 코드와 같이 ApplicationContext라는 인터페이스와 AnnotationConfigApplicationContext라는 구현체를 통해서 만들 수 있다.//스프링
동기와 비동기(Sync,Async)동기적 : 말 그대로 어떠한 일들이 동시에 일어난다는 뜻이다. 일상에서 접할 수 있는 동기화의 어원이라 볼 수 있으며, 요청과 동시에 그 응답이 요청을 요구한 자리에 시간과 관계없이 주어져야 한다. 즉,
AppConfig 리팩토링현재 AppConfig 클래스의 경우, 중복이 존재하고 역할에 따른 구현이 보이지 않는 구조이다.아래의 그림과 같이 명확히 구현을 나누어서 리팩토링을 해야한다.기대하는 AppConfig 구조리팩토링 전의 코드package hello.core; import hello.core.discount.FixDiscountPolicy;
새로운 할인 정책 개발현재는 정액 할인 정책을 채택하여 DiscountPolicy를 구현하고 있는데, 정률 할인 정책을 채택하여 DiscountPolicy를 변경하려한다.다행히 객체지향적으로 설계해서 유연하게 변화에 대응가능하다.RateDiscountPolicy 클래스 생성package hello.core.discount; import hello.core.member.