빈 스코프와 종류 빈 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 다양한 스코프 싱글톤: 기본 스코프, 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프 프로토타입: 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더 이상은 관리하지 않는 매우 짧은 범위의 스코프 웹 관련 스코프: request, session, application 등 빈 스코프는 애노테이션 @Scope("특정 스코프(예:prototype)")으로 지정할 수 있다. 프로토타입 스코프 싱글톤 스코프 빈을 조회하면 스프링 컨테이너는 항상 같은 인스턴스의 스프링 빈을 반환한다. 반면 프로토타입 스코프 빈을 조회하면 스프링 컨테이너는 항상 새로운 인스턴스를 생성해서 반환한다.(프로토타입 빈을 2번 조회..

빈 생명주기 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면, 객체의 초기화와 종료 작업이 필요하다. 스프링 빈의 라이프 사이클을 간략하게 설명하면 객체 생성 후 의존관계를 주입한다. 즉, 스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 후에 필요한 데이터를 사용할 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 끝나고 난 다음 호출해야 한다. 개발자는 의존관계 주입이 끝난 시점을 어떻게 알 수 있을까? 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링은 스프링 컨테이너가 종료되기 직전에 소..

컴포넌트 스캔 스프링 빈은 자바 코드나 XML의 Bean을 통해 직접 등록하지만 이러한 작업은 등록할 빈이 많아질수록 설정 정보가 커지고 누락하는 문제도 발생한다. 스프링은 이러한 등록절차 없이도 자동으로 스프링 빈을 등록하는 '컴포넌트 스캔' 기능을 제공한다. 설정정보뿐만 아니라 의존관계도 자동으로 주입할 수 있도록 '@Autowired' 기능을 제공한다. 컴포넌트 스캔 기능을 사용하기 위해서는 설정 정보 클래스에 @ComponentScan 애노테이션을 붙여주기만 하면 된다. 별도의 빈을 등록할 필요 없이 말이다. 이 애노테이션은 @Component가 붙은 클래스를 스캔해서 스프링 빈에 등록한다. 설정 정보 클래스에는 @Configuration 애노테이션을 붙이게 되는데, 이 애노테이션 소스코드에는 @..

싱글톤 패턴과 싱글톤 레지스트리 스프링이 처음 설계됐던 대규모 서버환경은 서버 하나당 최대로 초당 수십에서 수백 번씩 브라우저나 여타 시스템으로부터 요청을 받아 처리할 수 있는 높은 성능이 요구되는 환경이었다. 또한 스프링은 다양한 기능을 담당하는 여러 오브젝트들이 계층형 구조로 이루어져 복잡했다. 이러한 상황에서 클라이언트 요청이 들어올 때마다 새로운 오브젝트가 생성되면 어떻게 될까? 자바의 기능이 향상되어도 수많은 객체가 생성되고 소멸되면서 서버가 감당하기 어려운 상황에 이를 것이다. 스프링은 이러한 문제점을 해결하기 위해 해당 객체를 딱 하나만 생성하게 하고 공유하게 하는 싱글톤 패턴을 사용한다. 싱글톤 패턴: 클래스의 인스턴스가 딱 1개만 생성되는 걸 보장하는 디자인 패턴이다. 싱글톤 패턴을 직접..

스프링 컨테이너란? ApplicationContext는 인터페이스로 스프링 컨테이너라 한다. 스프링 컨테이너는 XML기반이나 애노테이션 기반의 자바 설정 클래스로 만들 수 있다. ApplicationContext(애플리케이션 컨텍스트)와 Bean Factory(빈팩토리)의 차이점 스프링에서는 빈의 생성과 관계설정 같은 제어를 담당하는 loC 오브젝트를 Bean Factory라고 한다. ApplicationContext는 Bean Factory와 동일한 기능을 제공하면서 부가적인 기능을 제공한다. 사실 ApplicationContext는 Bean Factory의 기능을 모두 상속 받기 때문에 Bean Factory와 동일한 기능을 제공할 수 있는 것이다. 부가기능: 메시지소스를 활용한 국제화 기능, 환경변..

객체 지향의 장점과 문제점 고객의 요구사항을 보면 지금 당장 결정하기 어려운 부분도 존재한다. 그렇다고 모든 부분이 결정날 때까지 개발을 기다릴 수 없다. 이런 상황에서 객체 지향 설계법은 유용하게 쓰인다. 인터페이스를 생성하고 이에 맞는 구현체를 만들어 놓으면 변경이 필요할 때 언제든 교체할 수 있기 때문이다. 예를 들어 한 업체가 아직까지 어떤 데이터베이스를 사용할지 결정하지 않았다고 가정하자. 인터페이스로 Repository를 생성하고 임시저장소로 TemporaryRepo를 구현체로 개발을 진행한다. 업체는 개발 도중 DbRepo를 사용하기로 결정했다면 DbRepo클래스를 만들어 인터페이스를 상속받아 구현하면 다른 코드의 변경없이 저장소를 변경할 수 있다. private final Repositor..