♪ 학습 내용 HTTP 응답 / HTTP 메시지 컨버터 * HTTP 응답 스프링에서 응답 데이터를 만드는 방식은 총 3가지이다. ( 정적 리소스 / 뷰 템플릿 사용 / HTTP 메시지 ) 정적 리소스 정적 리소스는 말 그대로 웹 브라우저에 정적 HTML CSS JS를 제공할 때 사용되는 것이다. 파일을 변경하지 않고 그대로 서비스하기 때문에 웹 브라우저 url 경로 입력하고 바로 실행하면 된다. 마치 src/main/resources/static/index.html 처럼. 뷰 템플릿 스프링이 제공하는 뷰 템플릿의 기본 경로는 다음과 같다. src/main/resources/templates ModelAndView를 생성하며 논리 이름을 넘겨 뷰 템플릿을 호출하거나 , Model에 데이터를 담고 논리 이름..

♪ 학습 내용 스프링 MVC - HTTP 요청 메시지( 텍스트 / json ) 조회 * HTTP 요청 메시지 조회 - 단순 텍스트 HTTP 요청 메시지 바디에 직접 데이터를 담아 요청하면, 앞에서 학습한 @RequestParam 이나 @ModelAttribute 를 사용할 수 없다. (두 애노테이션은 요청 파라미터를 조회하는 방식이기 때문!) 그렇기 때문에 서블릿 학습 때 처럼 inputStream을 받아, StreamUtils를 이용해야한다. StreamUtils를 이용해 바이트 코드인 inputStream을 UTF-8로 변환. (InputStream inputStream, Writer writer) InputStream은 request, response 를 파라미터로 받지 않고 바로 요청 메시지 바디..

♪ 학습 내용 스프링 MVC - HTTP 요청 파라미터 조회 * HTTP 요청 헤더 조회 HttpMethod => HTTP 메서드를 조회한다. ex) GET , PUT ,,, 등 Locale => Locale정보를 조회한다. ex) ko_KR , en_US ,,, 등 @RequestHeader @RequestHeader MultiValueMap headerMap 모든 HTTP 헤더를 MultiValueMap형식으로 조회 MultiValueMap은 Map과 유사하며, 하나의 키에 여러 값을 받을 수 있다 ! 따라서 MultiValueMap에서 여러 값이 저장된 키 하나를 조회하면 해당 값들이 속한 List 배열로 반환한다. @RequestHeader("host") String host 특정 HTTP 헤더를..

♪ 학습 내용 스프링 MVC의 기본 기능 이번엔 JSP를 사용하지 않기 때문에 프로젝트 생성 시 Jar를 선택해주었다. Jar : 항상 내장 서버 사용, webapp 경로 사용x ----> 내장 서버 사용에 최적화 * 로깅 //로그 선언 private Logger log = LoggerFactory.getLogger(getClass()); //치환된다 log.deug("data={}",data); @Slf4j 장점으로는 로그를 사용하면 로그를 상황에 맞게 설정으로 조절할 수 있고, ( ex 개발 서버에는 모든 로그 출력, 운영 서버에는 출력하지 않는 로그) System.out 방식은 콘솔에 출력하는 것이 전부였지만 로그는 파일이나 네트워크 등 별도의 위치에 남길 수 있다. * 요청 매핑 @RestCont..

♪ 학습 내용 스프링 MVC 시작 * 스프링 MVC 시작하기 전에는 Controller 인터페이스를 구현한 컨트롤러로 개발했지만 스프링이 제공하는 컨트롤러는 애노테이션을 기반으로 훨씬 더 편리하게 개발 가능하다. @Controller 1. 스프링 빈으로 등록 ( 내부에 @Component가 포함되어 있다) 2. 스프링 MVC에서 애노테이션 기반 컨트롤러로 인식 @RequestMapping 요청 정보를 매핑한다. 해당하는 URL이 호출되면 이 메서드 호출! 이 애노테이션이 있으면 RequestMappingHandlerMapping / RequestMappingHandlerAdapter 이 두 객체가 사용된다. (우선순위 제일 높음) 현재 실무에서는 이 방식의 컨트롤러를 사용 RequestMappingHan..

♪ 학습 내용 스프링 MVC의 전체 구조 이해 * 스프링 MVC 구조 스프링 MVC의 전체 구조는 다음과 같다 앞서 개발해온 MVC 프레임워크와 구조가 매우 유사한 것을 확인했다. 요청이 들어오면 핸들러 매핑에서 돌면서 핸들러를 찾고, 핸들러 어댑터 목록에서 돌면서 핸들러를 처리가능한 어댑터를 찾는다. 어댑터를 통해 핸들러 실행되고, ModelAndView 반환되고 논리 이름으로 뷰 리졸버 --> 실제 뷰 반환 렌더 호출해서 뷰 렌더링 된다. 스프링 MVC의 프론트 컨트롤러이자 핵심이 바로 DispacherServlet. DispacherServlet은 부모 클래스에서 HttpServlet을 상속 받는다. 스프링 부트는 내장 톰켓을 띄우면서 이 DispacherServlet을 바로 서블릿으로 등록한다. ..

♪ 학습 내용 더 실용적이고 유연한 컨트롤러 개선 (model을 파라미터로 / 어댑터 패턴 적용) * model을 파라미터로 앞에서는 컨트롤러에서 ModelView 객체 생성하고 다시 반환해야했다. 어떻게 보면 귀찮은 작업..! 그래서 컨트롤러는 ModelView가 아닌 ViewName만을 반환하게끔 개선했다. 그렇다면 model은 어떻게 처리하지 ? 싶었지만 Map으로 구현한 model을 프론트 컨트롤러에서 컨트롤러를 호출할 때 파라미터로 넘겨주었다. 즉, 컨트롤러 입장에서는 파라미터로 넘어온 Map(model)에 데이터만 넣고, 반환은 뷰 이름만 반환하면 된다. 위의 프론트 컨트롤러에서 model 객체 (Map)를 생성하여 컨트롤러에게 파라미터로 넘기는 것을 확인 ! 그리고 논리 이름인 ViewNam..

♪ 학습 내용 MVC 프레임워크 개선( view 분리 / 컨트롤러의 서블릿 종속성 제거 / 뷰 이름 중복 ) * View 분리 앞서 만든 코드에서는 각 컨트롤러마다 다음 코드가 중복 작성됐었따. RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath); dispatcher.forward(request,response); 중복을 제거하기 위해 뷰 코드를 처리하는 MyView 객체를 만들었다. public MyView(String viewPath){ this.viewPath = viewPath; } viewPath를 생성자 파라미터로 가진다. 각 컨트롤러에서는 매번 forward 할 필요 없이 MyView 객체를 생성하고, 프론트 컨트롤러에..

♪ 학습 내용 프론트 컨트롤러란 ? / 프론트 컨트롤러 도입 * 프론트 컨트롤러 이전 학습에서 공통처리로 인한 MVC 패턴의 한계를 알아보았다. 기존에는 클라이언트가 직접 컨트롤러(서블릿)를 호출하므로 각 컨트롤러 마다 공통 로직이 필요했다(중복). 하지만 프론트 컨트롤러를 도입한다면 ? 프론트 컨트롤러를 도입함으로써 입구는 하나가 되었고, 모든 클라이언트의 요청은 프론트 컨트롤러만을 호출한다. 그리고 프론터 컨트롤러는 고객의 요청을 받고 이에 매핑되는 컨트롤러를 호출해준다. 궁극적으로는 프론트 컨트롤러에 공통 처리를 몰아서, 공통 처리하기 좋아졌다. 클라이언트의 요청을 받는 프론트 클라이언트는 서블릿이다. 그렇다면 나머지 컨트롤러는? 서블릿이 아니지만, 서블릿과 유사한 구조를 지닌 인터페이스로 구현한다..

♪ 학습 내용 MVC 패턴과 한계 * MVC 패턴 Model : 뷰에 출력할 데이터를 담는다. 따라서 뷰는 모델을 통하여 렌더링에만 집중 View : 모델에 담겨있는 데이터를 이용하여 화면에 렌더링 --> HTML 생성 Controller : HTTP 요청을 받아 비즈니스 로직 실행(서비스 계층 이용), 뷰에 전달할 데이터를 모델에 담는다 컨트롤러로 서블릿을, 뷰로 JSP를 사용했다!! 데이터를 담을 Model은 ?? request.setAttribute(); request.getAttribute(); HttpServletRequest 객체 내부에 데이터를 담음으로써 request 객체를 모델로 사용하였다. 대충 서블릿의 service에서 request에 데이터를 담고, JSP(뷰)에서 꺼내 사용! Re..