Steady and right

Spring Framework는 기능이 많은 만큼 환경이 매우 복잡한 편이다 이에 어려움을 느끼는 사용자들을 위해 만든 것이 바로 스프링 부트다 Spring Boot 스프링 부트의 공식문서에서 밝히는 이들의 목표는 아래와 같다 • 모든 Spring 개발에 대해 근본적으로 더 빠르고 광범위하게 액세스 할 수 있는 시작 환경을 제공한다 • 대규모 프로젝트 클래스 (내장 서버, 보안, 매트릭, 상태확인 및 외부 구성)에 공통적인 기능 등을 제공한다 • 코드 생성 및 XML 구성 요구 사항이 없다 기존의 Spring과의 차이점을 대략 정리해 보자면 아래와 같다 1. 내장 톰캣 내장 톰캣을 사용하기 때문에 따로 톰캣을 설치하거나 매번 버전을 관리해 주지 않아도 된다 2. stater를 통한 dependency를 ..

이전 글에서 스프링 프레임워크의 핵심인 POJO , IoC/DI , AOP , PSA를 살펴보았다 여기서 좀 더 나아가 스프링 프레임워크의 구조는 어떻게 되어 있는지 살펴보고자 한다 Module(모듈) 프로그램의 기능을 독립적인 부품으로 분리한 것을 모듈이라고 한다 그 자체로서 컴파일이 가능한 단위이며 재사용이 가능하고 동시에 여러 다른 모듈이 개발에 사용될 수 있다 이를 좀 더 쉽게 풀어보자면 여러 코드들이 모여 어떤 기능을 처리하는 덩어리라고 생각하면 될 듯하다 (jar파일들이 수많은 기능을 가진 클래스들로 묶여있으니 이 또한 하나의 모듈이다) 이렇게 각각의 모듈들을 구성하여 만든 것이 바로 Spring Framework다 Spring Framework (4.3.13 기준) 스프링 프레임워크는 총 2..

Web Scope 웹 스코프는 웹 환경에서만 동작하는 특징을 가지고 있으며 프로토타입 스코프와 다르게 종료 시점까지 스프링 컨테이너가 관리하기 때문에 종료 메서드를 호출해준다 웹 스코프를 사용하는 이유는 클라이언트에게 서비스를 제공하다 문제가 생겼을 때 보통 로그를 확인하여 디버깅을 진행한다 하지만 이때 동시에 접속한 여러 고객들의 요청이 뒤죽박죽 섞여 있으면 아주 힘든 상황이 될 것이다 그래서 공통적인 포맷으로 깔끔하게 로그들이 정리되어서 출력되도록 해주는 것이 웹 스코프의 역할이다 웹 스코프의 종류는 아래와 같이 다양하다 1. request HTTP 요청에 하나가 들어오고 나갈 때까지 유지되는 스코프이다 각각의 HTTP요청 마다 별도의 빈 인스턴스가 생성되고 관리된다 2. session HTTP Se..

데이터베이스나 커넥션 풀, 네트워크 소켓처럼 애플리케이션이 시작하는 시점에 연결을 미리 해야 하는 상황이 있다 이때 종료시점에 맞춰 연결을 모두 종료하려면 객체의 초기화와 종료 작업이 필요하다고 한다 초기화 같은 작업은 빈 객체를 생성하고 의존관계의 주입이 끝난 다음에야 필요한 데이터를 사용할 수 있도록 준비가 된다 즉 개발자가 언제 의존관계가 주입이 되는지를 알아야 한다 Bean 생명주기 의존관계를 알기 위해서는 우선 빈의 생명주기를 알아야 한다 스프링 빈은 대략적으로 아래와 같은 생명주기를 가지고 있다 (초기화 콜백: 빈이 생성되고 빈의 의존관계 주입이 완료된 후의 호출) (소멸 전 콜백: 빈이 소멸되기 직전의 호출) 이때 생성자 주입의 경우 스프링 빈이 생성됨과 동시에 의존관계가 주입이 되며(파라미..

스프링 컨테이너에 빈을 등록하기 위해서는 @Bean이나 XML의 을 통해서 직접 등록할 수도 있지만 수많은 스프링 빈을 등록할 때는 매우 비효율적이다 Component @Bean이나 을 사용하지 않고 빈을 등록할 수 있게 스프링은 Component Scan(컴포넌트 스캔)을 제공하는데 말 그대로인 컴포넌트 '스캔'을 위해서 '컴포넌트'를 먼저 등록해주어야 한다 @Component public class MemoryMemberRepository implements MemberRepository {} 이렇게 등록된 컴포넌트들은 컴포넌트 스캔이 이 어노테이션의 여부를 보고 스프링의 빈으로 등록하게 된다 Component Scan 컴포넌트 스캔이 어노테이션들을 조회할 기준은 base package를 통해 결정된..

스프링으로 주로 개발되는 웹 애플리케이션의 경우 대부분 여러 고객이 동시 요청을 하는 상황이 발생되게 된다 이때 요청마다 새로운 객체를 생성한다면 수많은 객체를 만들어야 할 것이고 트래픽이 많아지게 되면 결과적으로는 굉장히 비효율적인 구조가 될 것이다 이렇게 객체를 새로 만드는 것보다 이미 존재하고 있는 객체를 조회하는 것이 메모리적으로는 비교할 수 없을 정도로 효율적이라고 한다 이로써 객체를 새로 만들지 않고 공유하게 해주는 싱글톤 패턴을 사용하면 문제점을 해결할 수 있다 Singleton Pattern(싱글톤 패턴) 싱글톤 패턴은 클래스의 객체를 딱 1개만 생성하여 이를 공유(조회)할 수 있게 해준다 public class SingletonService { // static 영역에 미리 객체를 1개 ..