Spring

단일 책임 원칙 (한 클래스는 하나의 책임만 가져야 한다. )하나의 책임이라는 것은 클 수도 있고 작을 수도 있다. 문맥과 상황에 따라 다르다. 책임은 기능이라고 해석할 수도 있다. 중요한 것은, 클래스가 변경되는 이유가 한 가지여야 한다는 것이다. 클래스를 변경했을

https://start.spring.io/ 에서 스프링 프로젝트를 생성해준다.1\. Project : Gradle - Groovy 선택 (Gradle은 Groovy를 기반으로 한 빌드 툴)2\. Spring Boot : 최신의 버전 선택3\. Project

스프링 프로젝트에서 각 테스트는 독립적으로 실행되고, 순서의 의존관계가 없다. 순서의 의존관계가 있는 테스트는 좋은 테스트가 아니다. 한 번에 여러 테스트를 진행하면 메모리에 이전 테스트의 결과가 남아 있어, 테스트가 실패하는 경우가 있다. 이를 해결하기 위해 @Aft

제어의 역전. 프로그래머가 개발을 할 때, 외부 라이브러리를 호출하여 객체의 생성부터 시작해서 메소드 호출, 소멸까지 모든 생명주기를 프로그래머가 제어한다면, 프로그램의 제어의 권한이 애플리케이션에 있다 라고 말한다. 이 프로그램의 제어를 외부 프레임워크가 한다면, 프

여기서 ApplicationContext는 인터페이스인데, 스프링 컨테이너라고 한다. 스프링 컨테이너는 애너테이션 기반의 자바 설정 클래스(AppConfig.class)로 만들 수도 있고, XML 기반으로도 만들 수 있다. XML기반으로는 잘 사용하지 않는다. 그림과

대부분 스프링 애플리케이션은 웹 애플리케이션이다. 웹 애플리케이션의 특성상, 보통 수많은 고객이 동시에 요청을 한다. 위와 같은 상황에서, 초당 만명의 클라이언트가 스프링 DI컨테이너에 요청을 하면, 초당 만개의 빈 객체가 생성되고 소멸되기 때문에 메모리 낭비가 심하

이렇게 스프링 빈을 @Bean을 통해서 직접 등록하는 방법도 있지만, 만약 등록해야 할 빈이 수백개가 된다면, 설정 정보도 커지고, 관리하기가 힘들어진다. 스프링은 이러한 문제를 해결하기 위하여 빈을 자동으로 등록해주는 컴포넌트 스캔 기능과 의존관계 자동 주입 기능을

스프링 빈에 의존관계를 주입하기 위해서는 네 가지 방법이 있다. 1\. 생성자 주입2\. 수정자 주입(setter 주입)3\. 필드 주입 4\. 일반 매서드 주입생성자 호출 시점에 딱 1번만 주입되고, 어떤 것도 의존관계를 변경할 수 없다. 프로그램을 컨테이너에 씌워서

자바에서 애너테이션 기반으로 코드를 자동으로 작성해주는 라이브러리이다. 클래스에 애너테이션을 붙여줌으로써 사용할 수 있다.만약 롬복에서 자동으로 생성해주는 setter, getter, constructor에 어떤 내부 로직을 추가해야 할 때, 사용하기 좋지 않을 수 있

@Autowired는 Type으로 스프링 빈을 조회한다. 따라서 applicationContext.getBean(DiscountPolicy.class)와 유사하게 동작한다. 그런데 DiscountPolicy 인터페이스의 구현클래스가 FixDiscountPolicy,

데이터베이스 커넥션 풀이나 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고 종료 시점에 연결을 끊는 작업을 수행하려면 빈 객체의 초기화와 종료가 필요하다. \*\* DB connection pool : 웹 애플리케이션 서버와 데이터베이스를 연결하는

빈 스코프란 스프링 DI 컨테이너에서 빈이 생성되고 소멸되기까지 빈이 존재하는 범위이다. 싱글톤 스코프 프로토타입 스코프 request 스코프 session 스코프 application 스코프 프로토타입 빈 스코프는 조회할 때마다 스프링 DI 컨테이너에서 새로운 빈 인

intro... 자바 서블릿에 대한 글에 이어서 스프링 디스패쳐 서블릿에 대해 한번 알아보겠다. 디스패쳐 서블릿 ? > 위와 같이 서블릿의 공통로직을 묶어서 프론트 컨트롤러 역할을 하는 것이 스프링 디스패쳐 서블릿이다. 카페 예에서, 주문을 받고, 계산을 하는 직원(