📌 웹 서버 (Web Server) HTTP 기반으로 동작한다. 정적 리소스 제공 + 기타 부가기능 정적 HTML, CSS, JS, 이미지, 영상 등을 주고받을 수 있음 e.g. NGINX, APACHE 📌 웹 애플리케이션 서버 (WAS - Web Application Server) HTTP 기반으로 동작한다. 웹서버의 기능 + @ (정적 리소스 제공 가능) 프로그램 코드를 실행해서 애플리케이션의 로직을 수행할 수 있음 동적 HTML, HTTP API (JSON) 서블릿, JSP, 스프링 MVC 기술 사용 e.g. Tomcat, Jetty, Undertow → 차이는 웹 서버는 정적 리소스(파일)을 전달하고, WAS는 애플리케이션 로직을 수행한다는 것이다. 📌 일반적인 웹 시스템 구성 - Web Serv..

📌 빈 스코프 기본적으로 스프링 빈은 스프링 컨테이너 시작 시 함께 생성되어 컨테이너가 종료될때까지 유지된다. 이것은 스프링 빈이 기본적으로 싱글톤 스코프로 생성되기 때문이다. 스코프는 빈이 존재할 수 있는 범위를 뜻한다. 싱글톤 : 기본 스코프, 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프이다. 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프 웹 관련 스코프 request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프 session : 웹 세션이 생성되고 종료될 때까지 유지되는 스코프 application : 웹의 서블릿 컨텍스트와 같은 범위로 유지되는 스코프 → 스코프는 클래스에 @Scope("prot..

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

📌 다양한 의존관계 주입 방법 ✅ 생성자 주입 @Component public class OrderServiceImpl implements OrderService { private final MemberRepository memberRepository; private final DiscountPolicy discountPolicy; @Autowired public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) { this.memberRepository = memberRepository; this.discountPolicy = discountPolicy; } } 생성자를 통해 의존관계를 주입받는 방법 클래..

📌 컴포넌트 스캔과 의존관계 자동주입 지금까지 스프링 빈을 등록할 때 @Bean을 사용해서 설정 정보에 직접 등록할 스프링 빈을 나열했다. 만약 등록해야 할 스프링 빈이 수십, 수백개가 되면 설정 정보도 커지고 누락할 수 있고 번거롭다. 스프링은 설정정보가 없어도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 또 의존관계도 자동으로 주입하는 @Autowired라는 기능도 제공한다. ✅ 코드에 적용 설정 정보에 @ComponentScan를 붙여준다. 빈으로 등록할 클래스에 @Component를 붙여준다. 의존 관계를 주입하기 위해서 생성자에 @Autowired를 붙여준다. ✅ 작동 원리 1️⃣ @ComponentScan @ComponentScan은 @Component가 붙은 모든 클래..

📌 웹 애플리케이션과 싱글톤 웹 애플리케이션은 보통 여러 고객이 동시에 요청을 한다. 스프링 없는 순수 DI 컨테이너인 AppConfig는 요청이 들어올 때마다 객체를 새로 생성한다. → 메모리 낭비 심함 해결 방안은 해당 객체가 딱 1개만 생성되고 공유하도록 설계하면 된다. → 싱글톤 패턴 📌 싱글톤 패턴의 문제점 싱글톤 패턴을 구현하는 코드 자체가 많이 들어감 의존관계상 클라이언트가 구체 클래스에 의존함 → DIP 위반 클라이언트가 구체 클래스에 의존해서 OCP 원칙을 위반할 가능성이 높음 테스트 하기 어려움 내부 속성을 변경하거나 초기화하기 어려움 private 생성자로 자식 클래스를 만들기 어려움 결론적으로 유연성이 떨어짐 📌 싱글톤 컨테이너 스프링 컨테이너는 싱글톤 패턴의 문제점을 해결하면서 객..

📌 스프링 컨테이너 //스프링 컨테이너 생성 ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class); ApplicationContext : 스프링 컨테이너 (인터페이스) AnnotationConfigApplicationContext : ApplicationContext 인터페이스의 구현체 스프링 컨테이너는 XML 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있음 XML 기반 컨테이너는 잘 사용하지 않고 애노테이션 기반의 자바 설정 클래스가많이 사용됨 📌 스프링 컨테이너의 생성 과정 1️⃣ 스프링 컨테이너 생성 스프링 컨테이너를 생성할 때는 구성 정보를 지정해주어야..

새로운 할인 정책 개발 기존의 고정 할인 금액 정책에서 정률 할인 금액 정책으로 변경하자는 요구사항이 들어왔다. 우리는 역할과 구현을 잘 분리해놨기 때문에 DiscountPolicy의 구현체로 RateDiscountPolicy를 추가하고 적용해주면 된다. 새로운 할인 정책 적용 방식의 문제점 public class OrderServiceImpl implements OrderService { // private final DiscountPolicy discountPolicy = new FixDiscountPolicy(); private final DiscountPolicy discountPolicy = new RateDiscountPolicy(); } 위 코드는 역할과 구현을 분리하고 다형성을 활용했지만 ..

예제 프로그램 만들기 프로젝트 생성 먼저 Spring initializer페이지에 들어가 빌드 도구, 언어와 버전 등을 선택하고 메타 데이터 정보를 입력한 후 Generate한다. (현재 최신버전인 2.6.4 버전은 빌드 시 오류가 발생해서 하위 버전인 2.5.10을 사용했다) 비즈니스 요구사항 회원 회원을 가입하고, 조회할 수 있다. 회원은 일반과 VIP 두가지 등급이 있다. 회원 데이터는 자체 DB를 구축할 수 있고, 외부 시스템과 연동할 수 있다. (미확정) 주문과 할인 정책 회원은 상품을 주문할 수 있다. 회원 등급에 따라 할인 정책을 적용할 수 있다. VIP 등급의 고객은 1000원을 할인해주는 정책을 적용한다. 할인 정책은 변경 가능성이 높다. 회사가 기본 정책을 아직 정하지 못했고 최악의 경..