[Spring] 스프링 MVC 정리 (1)

서블릿

• @WebServlet ( name = "helloServlet" , urlPattern = "/hello" )
• HttpServletRequest : 요청정보 사용
• HttpServletResponse : 응답 정보 사용
  • WAS는 Request, Response 객체를 만들어 서블릿 객체를 호출
  • Request 객체에서 HTTP 요청 정보를 꺼내서 사용
  • Response 객체에 HTTP 응답 정보를 입력
  • WAS는 Response 객체에 담긴 내용으로 HTTP 응답 정보 생성

서블릿 컨테이너

• 서블릿은 지원하는 WAS를 서블릿 컨테이너라고 함
• 서블릿 컨테이너는 객체를 생성, 초기화, 호출, 종료하는 생명주기를 관리
• 서블릿 객체는 싱글톤으로 관리
  • 최초 로딩시점에 서블릿 객체 생성하고 재활용
  • 모든 고객의 요청이 동일한 서블릿 객체 인스턴스에 접근
  • 서블릿 컨테이너 종료시 객체도 함께 종료
• 동시 요청을 위한 멀티 쓰레드 처리 지원

---

멀티 쓰레드

장점

• 동시 요청 처리 가능
• 리소스(CPU, 메모리)가 허용할 때 까지 처리 가능
• 하나의 쓰레드가 지연되어도 나머지 쓰레드는 정상 작동

단점

• 쓰레드 생성비용이 비쌈
• 컨텐스트 스위칭 비용 발생

쓰레드 풀

• 쓰레드 풀에 생성 가능한 최대치를 관리해서 과도한 요청을 안전하게 처리
  • max thread 가 낮으면 서버 리소스는 여유롭지만 클라이언트 응답이 지연될 수 있음
  • max thread 가 높으면 CPU,메모리 리소스 임계점 초과로 서버 다운될 수 있음
• 쓰레드를 생성하고, 종료하는 비용(CPU)가 절약되고 응답속도가 빠름

---

HTTP 페이지

• WAS를 통해서 DB에서 주문 정보를 조회
• JSP or 타임리프를 이용해서 동적으로 HTML을 생성

HTTP API

• HTML이 아닌 데이터를 전달 ( 주로 JSON 사용 )

---

SSR - 서버 사이드 렌더링 (백엔드)

• HTML 최종 결과를 서버에서 만들어서 웹 브라우저에 전달
• JSP, 타임리프를 사용 

CSR - 클라이언트 사이드 렌더링 (프론트엔드)

• HTML 결과를 js로 웹 브라우저에서 동적으로 생성해서 적용
• 주로 동적인 화면에 사용하고, 필요한 부분을 변경할 수 있다.
• React, Vue.js

---

서블릿 -> JSP -> 서블릿 & JSP 조합 ( MVC 패턴 ) -> MVC 프레임워크 -> 스프링 MVC

서블릿

• HTML 생성이 어려움

JSP

• HTML 생성은 쉽지만, 역할이 너무 많음 with 비지니스 로직

스프링  MVC

• 애너테이션 기반 ( @Controller )
• 스프링 부트 
  • 서버 내장 -> 빌드 배포 단순화

 

HTTP 요청 방법 

• GET - 쿼리 파라미터
  • 메세지 바디 없이 URL 쿼리 파라미터에 포함
• POST - HTML Form
  • 메세지 바디에 쿼리 파라미터 형식으로 전달
  • content-type: application/x-www-form-urlencoded
• HTTP message body 
  • HTTP API 에서 주로 사용 ( JSON ) 
    • POST / PUT / PATCH

---

서블릿 -> JSP -> 서블릿 & JSP 조합 ( MVC 패턴 ) -> MVC 프레임워크 -> 스프링 MVC

서블릿

• 서블릿과 자바코드를 사용해서 동적인 HTML 만들 수 있다. 
• 서블릿을 이용해서 동적인 HTML 생성
• BUT 자바 코드로 HTML 문서를 만드는 것이 너무 비효율 적  -- 자바 코드안에 HTML
  • then HTML문서에 동적인 변화가 필요한 부분만 자바 코드로 넣을 수 있는 템플릿 엔진을 사용!!
  • Templete 엔진 종류 : JSP(사용 안함), Thymeleaf , Freemarker, Velocity 

JSP

• HTML 문서처럼 작성하고, 필요한 부분에 자바코드를 같이 사용 -- HTML 문서에 동적인 부분만 자바코드
• BUT 너무 많은 코드가 노출되고, JSP가 많은 역할을 수행 (유지보수 지옥)

 

MVC 패턴

• 역할 분리를 통해 서로 다른 라이프 사이클을 관리하기 유리하다. (유지보수 굿)
• MODEL 
  • VIEW에 출력할 데이터를 담는 역할
  • 비지니스 로직, 데이터 접근 상관 x 
  • 화면 렌더링에 집중
• VIEW 
  • MODEL에 담겨있는 데이터를 참조해서 화면에 그리는 역할
  • HTML 생성
• CONTROLLER
  • HTTP의 요청을 받아 파라미터 검증
  • Business 로직 -> Service 계층에 위임 
  • VIEW에 전달할 데이터를 조회해서 모델이 담는 역할
  • DispatcherServlet -- Controller의 중복을 공통처리 하는 역할
    • 클라이언트의 요청을 받음
    • 요청에 맞는 Controller 매칭

 

스프링 MVC 

• 애너테이션 기반 동작으로 유연하고 실용적
• @RequestMapping
  • RequestMappingHandlerMapping (핸들러 매핑)
  • RequestMappingHandlerAdapter (핸들러 어댑터)
  • 요청 정보를 매핑해서, 해당 URL이 호출되면 이 메서드를 호출한다. 
  • URL 매칭 뿐만 아니라, HTTP Method도 함께 구분 가능

@RequestMapping(value = "/new-form", method = RequestMethod.GET)

• @Controller
  • 스프링이 자동으로 스프링 빈에 등록 
  • 내부에 @Component를 포함 -->  component Scan의 대상
  • 스프링 MVC에서 애너테이션 기반 컨트롤러로 인식
• ModelAndView ( 학습 필요 )
  • 모델과 뷰의 정보를 담아서 반환
  • 스프링이 제공하는 ModelAndView를 통해 Model 데이터를 추가할 떄 addObject() 사용
  • addObject() 사용해서 얻은 데이터는 이후 뷰를 렌더링 할 때 사용

ModelAndView mv = new ModelAndView("save-result");
mv.addObject("member", member);
return mv;

---

로그 사용

• @Slf4j 롬복 사용
• log.info("hello")와 같이 사용 가능

 

@RestController ( @Controller + @ResponseBody 결합 )

• @Controller 의 경우 반환값이 String일 경우 뷰 이름으로 인식해서 뷰를 찾고 렌더링한다. 
• @RestController 의 경우 반환값을 HTTP 메세지 바디에 입력한다. 

 

@RequestMapping

  @PathVariable 

• @RequestMapping URL 경로를 템플릿화에 사용
• @PathVariable
  • PathVariable 이름과 파라미터 이름이 같으면 생략 가능
• @RequestParam
  
  • HTTP 요청 파라미터를 위 애너테이션으로 받을 수 있다. 
  • @RequestParam('username') String username= request.getParameter('username')
    • 파라미터 이름과 변수 이름이 같으면 ('username' ) 생략 가능 
    • String, int, Inteager 단순 타입이면 @RequestParam도 생략 가능
• @RequestParam.required
  • 파라미터 필수 여부 (기본 값 true )
• requestParamDefault
  • default값 설정 가능 
  • required 무의미

public String requestParamRequired(
@RequestParam(required = true) String username,
@RequestParam(required = false) Integer age)

@RequestParam(required = true, defaultValue = "guest") String username,
@RequestParam(required = false, defaultValue = "-1")

 

조건 매핑

• 특정 헤더 조건
• 특정 파라미터 조건 매핑

@GetMapping(value = "/mapping-header", headers = "mode=debug")
headers="mode"
headers="!mode"

@GetMapping(value = "/mapping-param", params = "mode=debug")
params="mode"
params="!mode"

 

@ModelAttribute

• 요청파라미터를 받아 객체에 값을 넣어주는 과정을 자동화 해준다. 
  • Data 객체 생성 - > 해당 객체의 프로퍼티를 찾아 Setter로 파라미터의 값을 입력
• 생략가능
  • RequestParam과 헷갈릴 수 있다.
    • 단순 타입(String, int, Integer)은 @RequsetParam 생략
    • 나머지 타입(argument resolver 지정 외)은 @ModelAttribute 생략

public String modelAttribute(@ModelAttribute Data Data)

 

HTTP message body 요청

• InputStream 이용
• InputStream, OutputStream = HTTP (요청/응답) 메세지를 (Body 내용을 직접 조회 / Body에 직접 출력) 
• HttpEntity
  • 스프링 MVC에서 지원 
  • HTTP header, body 정보를 편리하게 조회
    • 메세지 바디 직접 조회
  • 응답에 사용
    • 메세지 바디 정보 직접 반환
    • 헤더 정보 포함 가능 
    • view 조회 기능 없음 x
  • 1) RequestEntity / 2) ResponseEntity 기능 포함
    • 1) HttpMethod, url 정보 추가, 요청에서 사용
    • 2) HTTP 상태 코드 설정 가능, 응답에서 사용

• RequestBody
  • HTTP 메세지 바디 정보를 편리하게 조회할 수 있다.
  • But 헤더정보가 필요하면 HttpEntity 사용 or @RequestHeader 사용
• ResponseBody
  • 응답 결과를 HTTP 바디에 직접 담아 전달할 수 있다. 

 

HTTP 요청 메세지 - JSON

• @RequestBody 사용

public String requestBodyJsonV3(@RequestBody HelloData data)

• 위와 같이 직접 만든 객체를 지정할 수 있다. (ModelAttribute 처럼)
• HttpEntity, @RequestBody를 사용
  • HTTP 메세지 컨버터가 바디의 내용을 원하는 문자나 객체로 변환
  • JSON도 객체로 변환 
• @RequestBody는 생략 불가능 ( 생략할 시... ModelAttrbute로 적용 )
• @RequestBody
  • JSON 요청 -> HTTP 메세지 컨버터 -> 객체로 변환
• @ResponseBody
  • 객체 -> HTTP 메세지 컨버터 -> JSON 응답

 

HTTP 응답 데이터 생성

• 정적 리소스
• 뷰 템플릿 (동적인 HTML)
• HTTP 메세지 사용 
  • HTTP API 제공하는 경우 HTML이 아닌 데이터 전달이다. 
  • 따라서 HTTP 메세지 바디에 JSON 형식으로 데이터를 담아 보낸다.

---