Spring

김영한 강사님의 강의 링크kyobobook link인프런 강의 내용을 간단하게 정리하고, 심화 내용은 전문가를 위한 스프링5 책으로 채워나갈 것이다!

클린코드의 저자 로버트 마틴이 정리한 5가지 설계 원칙단일 책임 원칙(Single Responsibility Principle)하나의 클래스는 하나의 책임만 가져야 한다.하나의 책임이라는 것은 모호하다.클 수도 있고 작을 수도 있다.문맥과 상황에 따라 다를 수 있다.중

스프링에서 왜 객체 지향이 언급될까?스프링은 DI(Dependency Injection)와 IOC(Inversion Of Control)로 결합도를 낮추어 다형성, OCP, DIP 원칙을 가능하도록 지원해 준다. 이 것을 활용해서 클라이언트의 코드를 수정없이 기능을 확

애플리케이션의 프레젠테이션 레이어를 구현할 때 일반적으로 사용하는 패턴이다. 서로 다른 컴포넌트에 대해 책임이 명확한 아키텍처를 정의하는 것이 주요 원칙이다. Model : 비즈니스 데이터와 사용자의 컨텍스트 내 애플리케이션의 상태를 나타낸다.사용자 프로필 정보, 쇼핑

Separation of Concerns, SoC소프트웨어 상에서 구조를 패턴, 역할, 기능 등 각각 맞게 분야 별로 분리해서 작성하는 것을 말한다. 분리해서 작성할 때, 특성에 맞게 하나의 역할을 부여해서 작성해야 한다. Spring에서 SoC를 통해서 결합도는 낮게

기존 프로그램은 클라이언트 구현 객체가 스스로 필요한 서버 구현 객체를 생성해서 연결하고 실행까지 맡았다. 즉, 구현 객체가 프로그램의 제어 흐름을 스스로 조종할 수 있었다. 하지만, AppConfig가 등장한 후, 구현 객체는 자신의 로직을 실행하는 역할만 담당하게

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

ApplicationContext은 스프링 컨테이너며 인터페이스이다.스프링 컨테이너는 xml으로 만들 수 있으나 요즘은 annotation 기반의 자바 설정 클래스로 만든다.(스프링 부트가 annotation 기반으로 작동하기 편리하게 되어있기 때문)참고스프링 컨테이너

빈 이름으로 조회이름없이 타입만으로 조회하고 싶을 때, 이름만 제거하고 타입명만 입력하여 사용하면 된다.구체 타입으로 조회타입으로 조회할 때, 같은 타입이 둘 이상 있으면 중복 오류가 발생한다.NoUniqueBeanDefinitionException.class타입으로

BeanFactory나 ApplicationContext를 스프링 컨테이너라고 한다. 1\. BeanFactory 스프링 컨테이너의 최상위 인터페이스스프링 빈을 관리하고 조회하는 역할을 담당getBean() 기능 제공직접 사용할 일은 거의 없고 ApplicationCo

스프링 컨테이너는 다양한 형식의 설정 정보를 받을수 있도록 유연하게 설계되어 있다.(.java, .xml, Groovy 등)기존에 공부했던 방법new AnnotationConfigApplicationContext(AppConfig.class)최근에 잘 사용하지 않는 방

스프링은 Bean에 관한 정보를 BeanDefinition으로 추상화 시켰기 때문에 다양한 설정 형식을 지원해 준다. (역할과 구현을 개념적으로 잘 나눈 것)xml을 읽어 BeanDefinition을 만들거나, java로 BeanDefinition을 만들면 된다. (스

스프링이 없는 DI 컨테이너인 AppConfig는 요청을 할 때 마다 객체를 새로 생성한다. (고객 트래픽이 초당 100일 경우, 초당 100개의 객체가 생성되고 소멸된다.) 따라서 메모리 낭비가 심하므로 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 해결 가능하

스프링 컨테이너는 싱글톤 레지스트리이다. 따라서 스프링 빈이 싱글톤이 될 수 있도록 보장해야 한다. 스프링은 클래스의 바이트 코드를 조작하는 라이브러리를 사용하기 떄문에 한 번의 호출로 끝이 날 수 있는 것이다. AnnotationConfigApplicationCont

전까지 스프링 빈을 등록하기 위해 자바 코드상으로 @Bean을 추가하거나 xml 파일의 <bean>을 통해 설정 정보에 직접 등록할 스프링 빈을 작성했다. 만약 설정 정보가 방대해지면, 누락되는 문제가 발생하고 하나 하나 수백개 이상의 빈을 반복적으로 등록하기 귀

프로젝트에 속해있는 모든 클래스를 컴포넌트 스캔할 경우 많은 시간이 소요된다. 따라서 꼭 필요한 위치부터 검색할 수 있도록 시작 위치를 지정해 줄 수 있다.basePackages는 탐색할 패키지의 시작 위치를 지정한다. 이 패키지를 포함해서 하위 패키지까지 모두 탐색한

현업에서 거의 사용할 일이 없다. excludeFilters는 간혹 사용할 때가 있긴 하다. 개인적으로 스프링이 제공하는 옵션을 변경하면서 사용하기 보다 스프링의 기본 설정에 맞춰 사용하는 것을 권장한다.includeFilters : 컴포넌트 스캔 대상으로 추가 지정e

컴포넌트 스캔에서 똑같은 이름의 빈을 등록하게 될 경우 어떠한 결과가 나올까?1\. 자동 빈 등록 vs. 자동 빈 등록컴포넌트 스캔에 의해 자동으로 스프링 빈이 등록되는데 이름이 같다면 스프링이 관련 오류를 발생시킨다.ConflictingBeanDefinitionExc

생성자 주입수정자(setter) 주입필드 주입일반 메서드 주입생성자를 통해서 의존관계를 주입하는 방법생성자 호출 시점에 딱 1번만 호출되는 것이 보장된다.불변, 필수 의존관계 사용클래스 내에 생성자가 1개만 있으면 @Autowired를 생략해도 의존관계가 자동적으로 주

최근에는 스프링을 포함해서 DI Framework 대부분들이 생성자 주입을 권장하고 있다.대부분의 의존관계 주입은 한 번 발생하면 애플리케이션 종료까지 의존관계를 변경할 일이 없다. 그리고 대부분의 의존관계는 애플리케이션 종료전까지 변경되면 안된다.수정자 주입을 사용할

Lombok 은 애노테이션 기반으로 코드를 자동적으로 생성해주고 완성해주는 라이브러리이다. 롬복이 자바의 Annotation Processor 기능을 이용해 컴파일 시점에 생성자 등을 자동으로 생성해준다. class를 열어서 확인해보면 애노테이션의 코드가 추가된 것을

@Autowired는 타입으로 조회하는데, 같은 타입의 빈이 2개 이상일 경우 문제가 발생하게 된다.예를 들어, DiscountPolicy의 구현체인 FixDiscountPolicy와 RateDiscountPolicy를 스프링 빈으로 선언한다. @Autowired를 이

@Qualifier("...")를 사용할 경우 컴파일 타임에서 타입 체크가 안된다. 따라서 애노테이션을 직접 생성해서 문제를 해결할 수 있다. 아래와 같이 새로운 애노테이션 자바 파일을 생성하면, 다른 클래스에서 @CustomAnnotation으로 사용할 수 있게 되고

데이터베이스 커넥션 풀, 소켓처럼 애플리케이션이 시작할 때 필요한 연결을 미리 구성하고 애플리케이션 종료할 때에는 연결을 모두 종료하는 작업을 하려면 객체의 초기화와 종료 작업이 필요하다. 또한 스프링은 다양한 방식의 생명주기 콜백을 지원한다.스프링 빈은 간단하게 다음

디폴트 값으로 지정되어 있는 싱글톤 스코프는 스프링 빈은 스프링 컨테이너가 시작될 때 같이 생성되고 종료될 때까지 유지된다. 스프링은 싱글톤이외에도 다양한 스코프를 지원한다.스코프 : 빈이 존재할 수 있는 범위싱글톤 : 디폴트 값, 스프링 컨테이너 시작과 끝까지 유지되

프로토타입 스코프의 빈은 클라이언트가 요청하면 새로운 객체 인스턴스를 생성하여 반환해주는데, 싱글톤 스코프의 빈과 같이 사용할 경우 의도한 대로 동작하지 않는다는 문제가 있다.먼저 스프링 컨테이너에 프로토타입 스코프의 빈을 직접 요청하는 과정을 정리해보았다.1\. 클라

싱글톤 스코프 빈과 프로토타입 스코프 빈을 같이 사용할 때 사용할 때마다 항상 새로운 프로토타입 스코프의 빈이 생성되지 않는다는 문제점이 있었다. 어떻게 하면 이 문제를 해결하고 올바른 의도대로 사용할 수 있을까?가장 간단한 방법으로 싱글톤 스코프의 빈이 프로토타입을

웹 환경에서만 동작하며 프로토타입과 다르게 스프링이 해당 스코프의 종료시점까지 관리하므로 종료 메서드가 호출된다.request : HTTP 요청 하나가 들어오고 나갈 때까지 유지되는 스코프, 각 HTTP 요청마다 별도의 빈 인스턴스가 생성되며 관리된다.session :

ObjectProvider를 사용해본다.Controller와 Service에서 request 스코프를 사용하는 Logger에다 적용한다. Provider의 getObject()로 myLogger를 가져오기만 하면 된다.getObject()를 호출하는 시점까지 reque

Spring Redis Cache