Post

스프링 MVC 1

웹 시스템 구성

  • 웹 서버 : 정적 리소스 처리
  • WAS : 애플리케이션 로직 처리
  • 물론 WAS도 정적 리소스를 처리 할 수 있다 하지만 여러 문제점이 있다.
    • WAS가 너무 많은 역할을 담당하게 되고 , 서버 과부하 우려가 있다.
    • 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있다.
    • WAS 장애시 오류 화면도 노출 불가능 (error 페이지)
  • 그렇기에 보통 정적 리소스는 웹 서버가 처리하고, 웹 서버가 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임하는 식으로 동작

서블릿

  • 웹에서 요청이 들어왔을 시 서버에서는 해당 요청의 메시지, 어떤 요청 메서드인지, 메시지 바디 내용 파싱 등 많은 처리가 필요하다

    image

  • 서블릿을 지원해주는 WAS들은 위의 초록색 박스 외의 필요한 처리들을 대신 해준다.

  • 또 HttpServletRequest, HttpServletResponse와 같은 객체를 만들어 개발자들이 Http 스펙을 매우 편리하게 사용할 수 있게 해준다.

    image

멀티 쓰레드

  • 쓰레드는 애플리케이션을 실행해주는 것이다.

  • 쓰레드가 없다면 자바 애플리케이션 실행이 불가능하고, 쓰레드 하나 당 하나의 코드 라인만 수행하기 때문에 동시 처리가 필요하면 쓰레드를 추가로 생성한다.-

  • 요청 마다 쓰레드 생성 시

    image

  • 이런 단점을 해결해주기 위해 쓰레드 풀을 사용한다.

  • 쓰레드 풀

    image

  • 쓰레드 풀의 주요 튜닝 포인트트 최대 쓰레드(max thread) 수이다.
  • 이 값은 애플리케이션 로직의 복잡도, CPU, IO 리소스 등을에 따라 다르기 때문에 성능 테스트를 통해 적절한 값으로 설정해야된다.

프론트 컨트롤러

  • 스프링은 클라이언트가 요청을 보낼 시 공통 코드를 처리하기 위해 프론트 컨트롤러 패턴을 사용한다. 스프링에서는 DispatcherServlet이 이러한 프론트 컨트롤러로 구현되어있다.

    image

  • 프론트 컨트롤러 특징

    • 프론트 컨트롤러 서블릿 하나로 클라이언의 요청을 받음
    • 요청에 맞는 컨트롤러를 찾아서 호출해줌
    • 공통 처리 가능
    • 프론트 컨트롤러를 제외한 나머지 컨트롤러는 서블릿 사용 X

스프링 MVC 구조

image

  • 요청 순서
    • 핸들러 매핑에서 스프링 빈의 이름으로 핸들러를 찾음
    • 찾았다면 핸들러를 실행할 수 있는 핸들러 어댑터를 목록에서 찾음
    • 핸들러에서 로직을 실행 후 그 결과를 핸들러 어댑터에서 처리 후 반환(ModelAndView로)
    • 뷰 리졸버에서 넘어온 ModelAndView에서 view를 랜더링 해준 뒤 반환
    • @ResponseBody가 붙었을 땐 뷰 리졸버 대신 HttpMessageConverter가 작동한다.

Handler Mapping

  • 들어온 요청 URL을 적절한 핸들러(컨트롤러) 메서드에 매핑하는 역할을 합니다.
  • 보통 RequestMappingHandlerMapping 구현체를 이용한다.

Handler Adapter

  • 핸들러(컨트롤러)를 실행하는 역할을 합니다. Handler Mapping을 통해 핸들러가 결정되면, DispatcherServlet은 해당 핸들러를 실행하기 위해 적절한 Handler Adapter를 사용합니다.
  • 로직이 실행 된 뒤 ModelAndView에 view path와 model을 담아 DispatcherServlet에 반환한 뒤 서블릿은 그 값을 뷰 리졸버로 넘겨준다.

  • 우선 순위

    1
    2
    3
    
    0 = RequestMappingHandleAdapter    : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용
    1 = HttpRequestHandlerAdapter      : HttpRequestHandler 처리
    2 = SimpleControllerHandlerAdapter : Controller 인터페이스 처리
    

View Resolver

  • 컨트롤러가 반환한 뷰 이름(String)을 실제 뷰(View) 객체로 변환하는 역할을 합니다.
  • 뷰 이름을 보고 적절한 뷰 템플릿을 이용해 랜더링해준다.

PRG (post/redirect/get)

PRG 사용 전

  • 만약 상품을 주문하는 페이지가 있다고 가정하자. 그 상품 데이터는 Post로 add 요청을 보내게 된다.
  • 그때 사용자가 계속해서 새로고침을 한다면 어떻게 될까?
  • 같은 요청이 반복해서 나가게 되고 주문이 중복으로 처리되는 심각한 문제가 발생한다.
  • 이런 문제를 해결하기 위해 PRG를 사용한다.

PRG 사용 후

  • 고객이 상품 요청을 보내면 주문 내역 화면으로 redirect 해준다.
  • 그럼으로써 주문이 완료되었으면 주문 내역 화면으로 리다이렉트 되기 때문에 새로고침을 해도 문제가 없다.
  • 새로고침을 계속해도 리다이렉트 된 주문 내역 화면만 요청 된다.

출처)

[스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 강의 - 대시보드인프런 (inflearn.com)](https://www.inflearn.com/course/스프링-mvc-1/dashboard)
This post is licensed under CC BY 4.0 by the author.