[SpringBoot] 웹서버, WAS, JSP, Servlet, MVC 패턴, MVC 프레임워크, Front Controller

 

 

 

 

이쁘게 그림도 넣고 설명하고 싶지만 지금은 공부만 하는걸로도 시간이 부족하다.. 일단 설명만,,

 

 

 

 

 

김영한의 스프링 MVC 1편

 

20240222

ㄱ) 웹서버, 웹 애플리케이션 서버(WAS)

     - 웹서버 : 정적 콘텐츠 처리

      - WAS : 동적 콘텐츠 처리. 애플리케이션 로직 처리.

      - 역할을 분리하여 과부하 방지 및 효율적인 리소스 관리. 분리 안하고 WAS만 쓰다가 WAS에 문제가 생기면 오류화면조차 보여주지 못함.

 

ㄴ) Servlet 객체

      - http 요청 메시지 파싱, 헤더 확인, 바디 내용 파싱, (비즈니스 로직 후), http 응답 메시지 생성, 시작라인, 헤더, 바디에 html 생성.

      - 위와 같이 비즈니스 로직 전, 후의 모든 과정을 대신 해줌.

      - 클라이언트로부터 http 요청을 받으면 WAS가 request, response 객체 생성 후 서블릿 객체 호출.

      - WAS 안에 있는 서블릿 컨테이너가 서블릿 객체를 자동으로 생성, 호출, 관리해줌.

      - 서블릿 객체는 스프링 빈과 같이 싱글톤으로 관리

      - http 요청을 받아서 쓰레드가 서블릿 객체 호출. WAS 내부에 쓰레드가 있음. mian 메소드를 실행하면 쓰레드 하나가 할당되서 한줄한줄 실행하는 것. 그래서 동시 처리가 필요하면 쓰레드를 추가로 여러개 생성해야 함.

      - 멀티 쓰레드를 위해 쓰레드 풀 사용. 쓰레드 200개(톰캣 기본 세팅 기준) 미리 만들어 놓고 http 요청오면 바로 꺼내 씀.

 

 

 

 

20240226

ㄱ) 백엔드 개발자가 데이터를 주는 방법

      1) 정적 리소스(html, css, 이미지, 영상)

      2) 동적 html 페이지

      3) HTTP API : 주로 JSON 형태로 데이터 통신. 앱, 웹브라우저(리엑트, 뷰 등)에서 호출. 서버간 호출(주문서버, 배송서버)

 

ㄴ) SSR, 서버 사이드 렌더링 : 동적 데이터를 포함한 html을 서버에서(백엔드 개발자가) 미리 다 만드는 것. JSP, 타임리프 등.

 

ㄷ) CSR, 클라이언트 사이드 렌더링 : 프론트 개발자가 백엔드로부터 데이터만 받아서 직접 동적으로 페이지를 만드는 것. 필요한 부분만 변경 가능(지도, 캘린더 등). 리엑트, 뷰 등.

 

ㄹ) 자바 웹 기술 역사 : 서블릿(1997) - JSP(1999) - 서블릿, JSP 조합 MVC패턴 – MVC 프레임워크(스트럿츠 등) - 스프링 – 스프링 부트(WAS 내장, 빌드 배포 단순화). 스프링 부트 이전에는 톰캣과 같은 WAS를 따로 띄우고 자바 소스를 빌드해서 WAR파일을 만들고 배포하는 과정이었음. 최신기술 Spring WebFlux 기술적 난이도 높고 RDB 지원 부족, MVC로도 빠름 등으로 아직 실무에선 잘 안씀.

 

ㅁ) 자바 뷰 템블릿 역사 : JSP – 프리마커, 벨로시티 – 타임리프(최선의 선택, 스프링 MVC와 기능 통합이 강력해서 스프링이 미는 템플릿)

 

 

 

 

20240303

ㄱ) 서블릿

      1) 서블릿 객체 만들기

      2) request 객체에서 데이터 확인하기, response 객체에 데이터 세팅하기

      3) request로 데이터 받는 법 : GET 쿼리 파라미터, POST html form, rest api body

      4) response 세팅 ; 상태코드, 쿠키, 리다이렉트, html 데이터 응답, rest api body json 응답

 

ㄴ) 서블릿으로 html response하는 웹 애플리케이션 만들기

ㄷ) JSP로 html response하는 웹 애플리케이션 만들기

 

ㄹ) 서블릿, JSP의 한계

      1) 너무 많은 역할 : 비즈니스 로직, 화면처리를 한 파일에서 해야함. 실무에선 수천줄.

      2) 변경의 라이프 사이클 : 로직을 수정해도 해당파일을 수정해야하고, 뷰를 수정해도 해당 파일을 수정해야함. 변경의 라이프 사이클이 다르다면 분리하는 것이 좋다.

 

ㅁ) MVC 패턴

       1) Controller(서블릿) : http 요청 받기, 파라미터 검증, 비즈니스 로직을 수행하는 서비스 호출. 결과 데이터 모델에 담기(request.setAttribute()).

       2) Model(HttpServletRequest request 객체의 attribute) : 뷰가 출력할 데이터를 담음. 그래서 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면 렌더링에 집중함.

       3) View(JSP) : 모델에 담겨있는 데이터(request.getAttribute())로 화면을 렌더링함.(html, xml 등 생성)

 

ㅂ) MVC 패턴의 한계 : Controller에 중복(뷰 경로, 뷰 호출을 위한 forward)이 많고 미사용 코드(HttpServletResponse response)가 있다. 그래서 Front Controller 라는 것을 앞에 추가로 두어서 중복처리를 공통적으로 한다.

 

 

 

 

20240304

ㄱ) MVC 프레임워크 만들기 - MVC패턴의 단점을 보완하기 위한 Front Controller 패턴

        1) MVC패턴에 존재하던 각각의 컨트롤러 앞에 공통처리를 먼저 해주는 프론트 컨트롤러(서블릿)를 두는 것 = 요청을 받는 입구가 하나. 프론트 컨트롤러를 서블릿으로 만들었기 때문에 이전의 컨트롤러들은 서블릿으로 만들 필요가 없다.

        2) Spring 웹 MVC도 DispatcherServlet 이라는 프론트 컨트롤러 패턴으로 만들어진 서블릿으로 동작하는 것이다.

        3) 프론트 컨트롤러에서 paramMap과 modelMap을 컨트롤러에게 넘긴다. 각 컨트롤러는 결과 데이터를 파라미터로 받은 modelMap에 put만 하면 된다.

        4) 뒤쪽으로 이동된 컨트롤러는 서블릿이 아니므로 서블릿과의 종속성을 없애기 위해 모델 역할을 했던, 서블릿에 종속적인 HttpServletRequest, HttpServletResponse 객체를 없애고, model을 put하고, 논리path(viewName) String을 리턴한다. == 각 컨트롤러에 있던 request.setAttribute 과정이 없어진다.

        5) 논리경로의 앞뒤를 붙여서 물리경로를 리턴해주는 viewResolver를 만든다.

        6) MyView에 modelMap에서 값을 꺼내서 request.setAttribute를 해주는 생성자를 만든다. 그리고 forward해서 html로 넘긴다. 이렇게 서블릿과의 종속성을 모두 프론트 컨트롤러가 가진다.

        7) 어댑터 패턴

        8) 핸들러 : 컨트롤러라는 이름을 더 넒은 범위인 핸들러로 변경한다. 왜냐하면 어댑터가 있기 때문에 컨트롤러뿐만 아니라 어떤 것이든 해당하는 종류의 어댑터만 있으면 다 처리할 수 있기 때문에 개념을 확장한 것이다.

        9) 핸들러 어댑터 : 말 그대로 중간에 어댑터 역할을 하는 어댑터이다. 이를 통해 다양한 버전의 컨트롤러를 사용할 수 있다.(ex 110v -> 220v 변환 어댑터)

        10) 프론트 컨트롤러에서 핸들러 매핑정보 가져옴(컨트롤러 v3인지 v4인지) -> 핸들러 어댑터 목록을 돌아서 해당 컨트롤러에 맞는 어댑터를 가져옴(v3, v4를 처리하는 방법이 다르므로 어댑터 필요) -> 핸들러 어댑터를 호출해서 해당 버전에 맞는 컨트롤러를 호출하고 model도 세팅 -> viewResolver로 물리경로 가져옴 -> forward해서 html로 넘김