스탠다드 강의를 들으면서 MVC 복습!

강의목표

---

💡 MVC 패턴은 무엇이고 어떻게 구성되어 있는가..?

기술의 흐름을 알려주는 이유

우리는 Spring, Spring Boot, JPA를 사용하는데
이것이 무엇인지 내부적으로 어떻게 동작하는지 모호하다.
기술의 발전 흐름과 각각의 기술들이 어떤 역할을 하는지 알아야
현재 상황에 맞는 코드를 구조(혹은 패턴)에 맞추어 자연스럽게 작성할 수 있다.

1. MVC 패턴 개요

• MVC 패턴은 왜 나오게 된걸까?

💡 Servlet이나 JSP만으로 비지니스 로직과 View Rendering 까지 모두 처리하면 너무 많은 역할을 하게되고 유지보수가 굉장히 어려워져서(책임이 너무 많음) 고안된 패턴이다. Web Application은 일반적으로 MVC 패턴을 사용한다.

ex) 비지니스 로직이 존재하는 파일에 HTML이 엄청나게 많다면..?

1. 사용자가 Client(브라우저)를 통해 서버에 HTTP Request 즉, API 요청
2. 요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성
   1. 약속된 HTTP의 규격을 맞추면서 쉽게 HTTP에 담긴 데이터를 사용하기 위한 객체
3. 설정된 정보를 통해 어떠한 Servlet에 대한 요청인지 찾는다.
4. 해당 Servlet에서 service 메서드를 호출한 뒤 브라우저의 요청 Method에 따라 doGet 혹은 doPost 등의 메서드를 호출
5. 호출한 메서드들의 결과를 그대로 반환하거나 동적 페이지를 생성한 뒤 HttpServletResponse 객체에 응답을 담아 Client(브라우저)에 반환
6. 응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse 객체를 소멸

1) Template Engine

• 동적인 웹 페이지를 생성하기 위해 사용되는 도구
  템플릿을 기반으로 정적인 부분과 동적인 데이터를 결합하여 HTML, XML 등의
  문서를 생성한다. 주로 UI를 구성하는데 활용된다.

• 템플릿 엔진이 나온 이유

  자바 코드로 HTML을 만들어 내는 것이 아닌 HTML 문서에 동적으로 변경해야 하는 부분만
  자바 코드를 넣을 수 있다면 더 편리하다.
  

• JSP(Java Server Pages)

JSP에서 동적인 처리부분은 결국 Servlet으로 변환되어 실행된다.

2) Servlet 과 JSP

View가 분리된 핵심은 변경에 있다

비지니스 로직과 View는 대부분 수정이 함께 일어나지 않고 각자 발생한다.
(서로에게 연관이 거의 없다, 동시에 변하는 경우는 기획이 변하는 경우)

연관 없는 코드끼리 함께 존재하는 이유가 무엇인가?
JSP같은 View Template 들은 화면을 Rendering하는 역할만 수행하는것이 가장 효과적이다.
MVC는 하나의 Servlet이나 JSP로 처리하던 것들을 Controller, View 영역으로 나눈것이다.

Controller

• HTTP Request를 받아서 Parameter를 검증하고, 비지니스 로직을 실행한다.
  View에 전달할 결과 Data를 조회하여 Model에 담아준다.
• Controller에도 비지니스 로직을 사용하기도 한다.
  하지만 이렇게되면 너무 많은 역할을 담당하기 때문에 일반적으로 비지니스 로직은
  Service Layer를 별도로 만들어 처리한다.(계층구조)
  이렇게 계층이 따로 존재하면 Controller는 Service를 호출하는 역할을 담당한다.

Model

• View에 출력할 Data를 담아둔다. View가 필요한 Data를 모두 Model이 가지고 있기 때문에 View는 비지니스 로직이나 Data 접근을 몰라도 되고 Rendering만 집중하면 된다.

View

• Model에 담겨있는 Data를 사용하여 화면을 Rendering 한다.

2. MVC 패턴

• Spring MVC를 의미하는것이 아닌 MVC 패턴 그자체

1) MVC 패턴의 문제점과 한계

• MVC 패턴을 적용하니 View는 Model에서 필요한 데이터를 참조하여 화면을 그리면된다. 하지만 Controller는?

• Controller 문제점

1. dispatcher.forward(request, response) View로 이동하는 forward가 항상 중복 호출된다.
2. String path= “/WEB-INF/views/new-form.jsp” View의 path를 입력(중복 작업)한다.
   1. 경로가 바뀌거나 JSP 이외의 확장자를 사용하려면 전체가 변경되어야 한다.
3. HttpServletResponse 객체를 사용하는 경우가 적다. (JSP에서 모두 해결하기 때문)
   1. HttpServletRequest와 Response는 Test 코드를 작성하기도 매우 힘들다.
      (Request Response를 내가 계속 만들어야 하나..ㅎ)
4. 공통 처리
   기능이 추가될수록 Controller에서 공통으로 처리해야 하는 부분들이 많아진다.
   ex) log 출력, 인증, 인가 등등..

단순히 공통 기능을 Method로 분리하면 될것같지만
이것 또한 항상 중복적으로 호출이 필요하다.
이때까지만 해도 요청이 들어오는 입구가 너무 많다!
Servlet이 호출되기 전에 공통 기능을 처리 해주는것이 바로
프론트 컨트롤러 패턴이다.(입구가 하나)

3. 프론트 컨트롤러 패턴

• 프론트 컨트롤러(Servlet) 하나에 모든 클라이언트측 요청이 들어온다.(공통 처리 가능)

1) 프론트 컨트롤러의 역할

• 모든 Request를 하나의 프론트 컨트롤러가 받는다.
• 공통 기능을 처리한다.
• 프론트 컨트롤러가 Request에 맞는 Controller를 찾아서(컨트롤러 매핑) 호출한다.
  • 프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다!
    → 일반 Controller들은 HttpServlet을 상속받거나 @WebServlet 등을 사용하지 않아도 된다.