240528 MVC 패턴

MVC 패턴이 나오게 된 배경

Servlet이나 JSP만으로 비지니스 로직과 View Rendering 까지 모두 처리하면

너무 많은 역할을 하게되고 유지보수가 굉장히 어려워져서(책임이 너무 많음)

고안된 패턴이다.

 

 

1. 사용자가 Client(브라우저)를 통해 서버에 HTTP Request 즉, API 요청을 합니다.

2. 요청을 받은 Servlet 컨테이너는 HttpServletRequest, HttpServletResponse객체를 생성합니다.

a. 약속된 HTTP의 규격을 맞추면서 쉽게 HTTP에 담긴 데이터를 사용하기 위한 객체입니다.

3. 설정된 정보를 통해 어떠한 Servlet에 대한 요청인지 찾습니다.

4. 해당 Servlet에서 service 메서드를 호출한 뒤 브라우저의 요청 Method에 따라 doGet() 혹은 doPost() 등의 메서드를 호출합니다.

5. 호출한 메서드들의 결과를 그대로 반환하거나 동적 페이지를 생성한 뒤 HttpServletResponse 객체에 응답을 담아 Client(브라우저)에 반환합니다.

6. 응답이 완료되면 생성한 HttpServletRequest, HttpServletResponse객체를 소멸합니다.

 

Template Engine

- 동적인 웹 페이지를 생성하기 위해 사용되는 도구

- 템플릿을 기반으로 정적인 부분과 동적인 데이터를 결합하여 HTML, XML 등의

문서를 생성한다. 주로 UI를 구성하는데 활용된다.

 

대표적인 예

- Thymeleaf → Spring과 통합이 잘 되어있다. 지원이 잘됨. 다양한 기능

- JSP → 예전엔 많이 사용했으나, 현재 안쓰는 추세

- FreeMarker

- Velocity

- Mustache

 

JSP(Java Server Pages)

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

 

 

Controller :HTTP Request를 받아서 Parameter를 검증하고, 비즈니스 로직을 실행한다

- View에 전달할 결과 Data를 조회하여 Model에 담아준다

- 비즈니스 로직은 Service Layer를 별도로 만들어 처리한다.(계층구조)

- 계층이 따로 존재하면 Controller는 Service를 호출하는 역할을 담당한다.

 

Model

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

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

 

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 출력, 인증, 인가 등등..

 

Servlet이 호출되기 전에 공통 기능을 처리 해주는것이 바로

프론트 컨트롤러 패턴이다.(입구가 하나)

 

프론트 컨트롤러 패턴

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

프론트 컨트롤러의 역할

- 모든 Request를 하나의 프론트 컨트롤러가 받는다.

- 공통 기능을 처리한다.

- 프론트 컨트롤러가 Request에 맞는 Controller를 찾아서(컨트롤러 매핑) 호출한다.

- 프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다

→ 일반 Controller들은 HttpServlet을 상속받거나 @WebServlet등을 사용하지 않아도 된다.

프론트 컨트롤러의 의문점

- FrontController 를 사용한다면 모든 컨트롤러에서 같은 형태의 응답을 해야하는가??

 

공통 처리 로직에 모든 컨트롤러가 연결되기 위해서는

모든 컨트롤러가 return 하는 결과의 형태가 동일해야 한다.

 

 

Dispatcher Servlet

 

💡 Spring MVC의 핵심은 프론트 컨트롤러(DispatcherServlet)이다.

- Spring도 결국 Servlet을 사용하고 있고 이것이 바로 DispatcherServlet 이다.

- Dispatcher Servlet은 사실 우리가 모르게 엄청나게 많은 역할을 해주고 있었다.

 

MVC 패턴 → 개선→ 프론트 컨트롤러 패턴 → 개선→ Spring MVC