MVC 패턴

Template Engine

동적인 웹 페이지를 생성하기 위해 사용되는 도구이며 템플릿을 기반으로 정적인 부분과 동적인 데이터를 결합하여 HTML, XML 등의 문서를 생성하는 역할을 수행

-> 우리가 흔히 말하는 UI를 만들며 SSR에 사용된다.

• 템플릿 엔진이 나온 이유는 자바코드로 HTML을 만들어내는 것이 아닌 HTML 문서에 동적으로 변경해야하는 부분만 자바 코드를 넣기때문에.

• 대표적인 템플릿 엔진
  - Thymeleaf : 스프링과 통합이 잘 되어있고, 다양한 기능 포함

  • JSP(Java Server Pages) : 예전에는 사용 지금은 별로 안씀

MVC 패턴 개요

Servlet이나 JSP만으로 비지니스 로직과 View Rendering까지 모두 처리하면 너무 많은 역할을 하게되고, 유지보수가 어려워져서 고안 된 패턴.

• Servlet만 사용하면 화면을 그리는 view 영역과 비지니스 로직이 다 섞여있음. 책임감이 너무 큼

• JSP는 Servlet에서 HTML을 만드는 부분 View가 분리됨. 그래도 책임이 커서 유지보수 어려움

• 그래서 생성하게 된 MVC(Model View Controller)영역.
  

1. Controller

1) HTTP Request를 전달받아 파라미터를 검증한다.
2) 비지니스 로직을 실행한다.
- 비지니스 로직을 Controller에 포함하게되면 Controller가 너무 많은 역할을 담당하게 되어 일반적으로 Service Layer를 별도로 만들어서 처리한다.
- Database와 상호작용 하는 Layer를 따로 구분하여 Repository Layer를 추가로 구성한다.
- 위와 관련된 자세한 내용인 Layered Architecture는 다음 강의에서 알아보자.
- Controller도 비지니스 로직을 포함할 수 있지만 일반적으로 Service Layer를 호출하는 역할을 담당한다.
3) View에 전달할 결과를 조회하여 Model 객체에 임시로 저장한다.

2. Model

1) View에 출력할 Data를 저장하는 객체이다.
2) View는 비지니스 로직이나 Data 접근을 몰라도 되고 View Rendering에만 집중하면 된다.(책임 분리)

3. View

1) Model 객체에 담겨져 있는 Data를 사용하여 화면을 Rendering 한다.

MVC 패턴의 문제점

• MVC 패턴을 적용 후 View의 역할은 필요한 데이터를 Model 에서 참조하여 화면을 그리는 역할만 수행하면 된다. 하지만 Controller에 해당하는 부분은 여전히 문제를 가지고 있다.

• 문제점

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

• 공통 기능 처리

  • 모든 컨트롤러에서 공통으로 적용되는 기능을 뜻한다.

프론트 컨트롤러 패턴

• Servlet(Controller)이 호출되기 전에 공통 기능을 하나의 Servlet에서 처리해주는 패턴이다.
  -> 입구가 오직 하나, 프론트 컨트롤러(Servlet)에서 공통기능을 처리하면 된다.
  

• 프론트 컨트롤러의 역할

1. 모든 요청을 하나의 프론트 컨트롤러가 받는다.
2. 공통 기능을 처리한다.
3. 요청을 처리할 수 있는 Controller를 찾아서 호출한다.(Controller Mapping)
4. 프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다.
   • 일반 Controller들은 HttpServlet을 상속받거나, @WebServlet을 사용하지 않아도 된다.

• 프론트 컨트롤러의 의문점
  • 공통 처리 로직에 모든 컨트롤러가 연결되기 위해서는 모든 컨트롤러가 return 하는 결과의 형태가 동일해야 한다.
  • 하지만, Controller 마다 로직이나 응답해야하는 결과는 당연히 다를테고 응답을 동일하게 맞추려고 한다면 해당 애플리케이션은 확장성, 유지보수성을 잃는다.
  • 공통 로직에서 응답별로 퍼즐을 다시 하나하나 처리할 수 있으나 공통 부분의 책임이 너무 커지게된다. 또한, 컨트롤러에서 반환되는 결과가 달라지면 공통처리 부분의 변경또한 불가피하다.

어댑터 패턴

• 다양한 컨트롤러(Handler)를 유연하게 만들기위해 어댑터 패턴을 도입. 컨트롤러들은 동일한 인터페이스를 구현하도록 하고 해당 인터페이스와 공통 로직 사이에 어댑터를 두어 유연하게 만든다. 서로 다른 인터페이스를 갖는 두 클래스를 연결해주는 패턴
  

1. 컨트롤러(Handler)는 비지니스 로직을 처리하고 알맞은 결과를 반환한다.
2. 어댑터는 공통 로직과 컨트롤러(Handler)가 자연스럽게 연결되도록 한다.
3. 프론트 컨트롤러는 공통으로 처리되는 로직을 수행한다.

• 어댑터 패턴 장점
  • 프론트 컨트롤러, 어댑터, 핸들러 모두 각자의 역할만 수행한다. (책임 분리)
  • 새로운 컨트롤러(Handler)가 추가되어도 컨트롤러와 어댑터만 추가한다면 공통 로직의 변경이 발생하지 않는다.