[스프링 핵심원리-기본편]

역할과 구현을 분리 역할과 구현으로 구분하면 세상이 단순해지고, 유연해지며, 변경도 편리해진다. 장점 클라이언트는 대상의 역할(인터페이스)만 알면 된다. 클라이언트는 구현 대상의 내부 구조를 몰라도 된다. 클라이언트는 구현 대상의 내부 구조가 변경되어도 영향을

SRP 단일 책임 원칙 Single responsibility principle 한 클래스는 하나의 책임만 가져야 한다. 하나의 책임이라는 것은 모호하므로 중요한 기준은 변경이다. => 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것 UI변경, 객체

스프링 컨테이너 : ApplicationContext 기존에는 개발자가 Appconfig를 사용해서 직접 객체를 생성하고 DI를 했지만 스프링 컨테이너를 통해서 사용할 수 있다. 스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정(구성) 정보

먼저 스프링 없는 순수한 DI 컨테이너를 테스트 해보자 우리가 만들었던 스프링 없는 순수한 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. 고객 트래픽이 초당 100이 나오면 초당 100개 객체가 생성되고 소멸된다! ==> 메모리 낭

지금까지 스프링 빈을 등록할 때는 자바 코드의 @Bean이나 XML의 등을 통해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 그렇다면 등록해야 할 스프링 빈이 수십, 수백개가 되면 일일이 등록하기도 귀찮고, 설정 정보도 커지고, 누락하는 문제도 발생한다. 그래서

생성자 주입 생성자 주입은 이름 그대로 생성자를 통해 의존관계를 주입받는 방법 생성자 호출 시점에 딱 한번만 호출되는 것이 보장된다. 주로 불변, 필수 의존 관계에 사용한다. 불변 : 처음에 세팅한 값을 변경하는 것을 허용하지 않는 것 필수 : 변수에 final 키

스프링 빈은 간단하게 다음과 같은 라이프사이클을 가진다.객체 생성 -> 의존관계 주입스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야

빈스코프란 ..?스코프는 번역 그대로 빈이 존재할 수 있는 범위를 뜻한다.싱글톤 : 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다.실행 결과프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는

웹 스코프 웹 스코프는 웹 환경에서만 동작한다. 웹 스코프는 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리한다. 따라서 종료 메서드가 호출된다. 웹 스코프 종류 request: HTTP 요청 하나가 들어오고 나갈 때 까지 유지되는 스코프, 각각의 H