요청 매핑 핸들러 어댑터 (RequestMappingHandlerAdapter) [Spring] HTTP 메시지 컨버터 뷰 템플릿으로 HTML을 생성해서 response하는게 아니라, HTTP API처럼 JSON형식의 데이터를 HTTP Message Body에 읽거나 쓸 경우 "HTTP 메시지 컨버터"를 사용하면 손쉽게 body의 데이터를 조작할 수 있다 JSON뿐 cs-ssupport.tistory.com 그러면 앞에서 설명한 HTTP 메시지 컨버터는 도대체 스프링 MVC 구조 어디서 사용되는 걸까?? 전형적인 스프링 MVC 구조에서는 HTTP 메시지 컨버터가 사용되는 부분을 찾을 수가 없다 그러면 여기서 {핸들러 어댑터 - 핸들러}부분을 더 자세히 살펴보자 Argument Resolver 사실 {핸들..

뷰 템플릿으로 HTML을 생성해서 response하는게 아니라, HTTP API처럼 JSON형식의 데이터를 HTTP Message Body에 읽거나 쓸 경우 "HTTP 메시지 컨버터"를 사용하면 손쉽게 body의 데이터를 조작할 수 있다 JSON뿐만 아니라 Message Body의 내용을 HTTP 메시지 컨버터가 알아서 binding을 해준다 스프링 MVC의 경우 다음 경우에 HTTP 메시지 컨버터를 적용한다 @RequestBody HttpEntity(RequestEntity) @ResponseBody HttpEntity(ResponseEntity) HTTP 메시지 컨버터 Interface HTTP 메시지 컨버터 Interface 내부 메소드에는 총 4가지가 존재한다 (1) canRead / canWri..

웹 & HTTP 웹 상에서 일어나는 모든 동작은 HTTP에 의해서 제어가 된다 Client (웹 브라우저) : HTTP Request Server : HTTP Response Client가 HTTP Reqeust Message를 통해서 "어떤 자료(html, text, image, ...)좀 주세요"라고 요청하면 Server는 logic을 수행하고 그에 따른 HTTP Response Message를 생성해서 Client에게 보내준다 [Network] HTTP 메시지 HTTP 통신 방식 1. 요청 - 응답 (Request - Response) 구조로 되어 있다 - Client가 HTTP Request를 보내면 Server가 HTTP Response를 보내준다 2. Stateless하다 - HTTP는 상태(..

빈 스코프 말 그대로 "빈이 존재할 수 있는 범위"를 뜻한다 지금까지는 스프링 빈이 "스프링 컨테이너 시작 ~ 종료까지 유지"된다고 하였다 이것은 스프링 빈이 "싱글톤"일 경우에만 해당된다 Singleton 스프링 컨테이너에서는 기본적으로 스프링 빈 객체들을 "싱글톤"으로 관리한다 싱글톤 빈은 스프링 컨테이너 시작 ~ 종료까지 유지되는 가장 넓은 범위의 스코프이다 따라서 싱글톤 빈의 생명주기는 스프링 컨테이너의 생명주기와 동일하다고 볼 수 있다 Prototype 프로토타입 빈은 스프링 빈과 전혀 다른 타입이다 스프링 컨테이너는 "프로토타입 빈의 {생성, DI, 초기화}"까지만 관리해주고 그 이후부터는 전혀 관여하지 않는다 따라서 스프링 컨테이너가 종료된다고 해도 "종료 메소드"가 호출되지 않는다 Prot..

빈 객체 생명주기 (초기화 & 소멸) DB 커넥션 풀이나 네트워크 Socket의 경우 "시작 시점에 미리 Connection을 설정해주거나 & 종료 시점에 연결을 안전하게 끊는 것"이 굉장히 중요하다 객체의 초기화 & 종료 작업이 필요/중요 기본적으로 스프링 컨테이너가 스프링 설정 클래스로부터 여러 스프링 빈을 찾으면 다음 작업을 수행해준다 스프링 빈 생성 DI 생성자 주입의 경우 스프링 빈이 생성될 때 DI도 같이 수행된다 setter나 field 주입의 경우 2단계가 나누어져서 진행된다 Spring은 DI까지 완료되면 스프링 빈에게 "너한테 DI까지 해줬으니까 초기화 과정 수행해라"라고 알려준다 >> 이 때 "초기화 콜백 메소드"를 통해서 알려준다 그리고 스프링 컨테이너를 종료하게 되면 여러 스프링 ..

@Component & @ComponentScan에 의해서 자동으로 빈을 등록해준다면 스프링 빈들의 DI를 굳이 수동으로 해줄 필요도 없고 수동으로 하면 복잡해진다. 따라서 자동 빈 등록에 대한 "의존관계 자동 주입"도 더불어서 가져가주는게 낫다 DI 방식 1. 생성자 주입 우리가 지금까지 사용하고 있던 방식이 "생성자 주입"이고 이 방식을 대부분 사용한다 생성자 주입의 특징은 다음과 같다 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다 불변/필수 의존관계에 사용된다 생성자는 객체가 생성될 때 딱 1번만 호출되기 때문에 만약 그때 DI가 된다면 이후에 변경될 일이 아예 없다 그리고 대부분 주입 대상을 필드 상에서 final로 지정하는데 final로 지정하면 초기화를 해주든 생성자에 넣어주든 해줘야 하..

컴포넌트 스캔 @Configuration public class AppConfig { @Bean public MemberRepository memberRepository(){ return new MemoryMemberRepository(); } @Bean public DiscountPolicy discountPolicy(){ //return new FixDiscountPolicy(); return new RateDiscountPolicy(); } @Bean public MemberService memberService(){ return new MemberServiceImpl(memberRepository()); } @Bean public OrderService orderService(){ return n..

웹 애플리케이션 & 싱글톤 웹 애플리케이션 거의 대부분 여러 user가 동시에 접속한다 여러명의 고객이 서비스에 join을 하기 위해 서로 memberService를 호출하게 된다면?? 만약 고객 트래픽이 초당 100이 나온다면 초당 100개의 memberService 객체가 생성되고 소멸된다 >> 이것은 굉장한 메모리 낭비이다 이러한 문제점을 해결하는 간단한 방법은 "해당 객체를 1개만 생성하고 여러 user가 공유하도록 설계"하면 된다. 이러한 방식을 "싱글톤 패턴"이라고 한다 싱글톤 패턴 싱글톤 패턴은 클래스의 인스턴스가 딱 1개만 생성되는 것을 보장하는 디자인 패턴이다 따라서 객체의 인스턴스가 2개 이상 생성되지 못하도록 막아줘야 한다 생성자를 private로 선언해서 외부에서 임의로 new를 통..

스프링 컨테이너 스프링 컨테이너는 스프링 빈 객체들의 생명 주기를 관리하고, 생성된 Bean 객체들에 대해서 부가적인 기능을 제공하는 역할을 한다. 빈 객체가 Singleton일 경우 해당되는 정의 Prototype일 경우 생명주기 전체를 관리하지 않고, 빈 객체의 초기화까지만 관여하고 이후에는 전혀 관여 X 일반적으로 코딩을하면 객체를 생성하는 것은 개발자가 해주는 일이다. 하지만 스프링 컨테이너는 IoC라는 제어의 역전 개념을 통해서 이러한 객체 관련 일들을 대신 해준다 그리고 의존 관계 주입(DI)도 스프링 컨테이너에서 빈 객체를 생성 후 자동으로 맺어준다 @Configuration으로 지정한 스프링 설정 클래스인 AppConfig를 "스프링 컨테이너"를 생성할 때 파라미터로 전달해준다 위 코드에서..