MVC 모델과 DispatcherServlet

MVC 모델이란? 

Model, View, Controller  철자를 따서 만들어진 합성어로 소프트웨어 공학에서 사용되는 디자인 패턴을 의미함.  각각의 의미는 아래와 같음.

 

• Model
  • 데이터베이스와 연동해서 사용자가 입력한 데이터나 사용자에게 출력할 데이터에 대한 비지니스 로직을 수행함.
  • 보통 Service나 Dao 등 비지니스 로직에 사용되는 클래스를 지칭함. (모델도 서비스계층과 영속계층으로 나뉨)
• View 
  • 모델이 처리한 데이터나 그 작업의 결과를  사용해서 사용자가 보게 될 화면을 생성함. 
  • View Template로는 JSP, Mustache, Thymeleaf 등이 존재함.
• Controller
  • 클라이언트의 요청을 받으면 실제 업무를 처리하는 모델을 호출함. 클라이언트에서 보낸 데이터가 있으면 모델을 호출하기전에 먼저 데이터를 처리하는 경우도 있음.
  • 모델이 작업을 완료하면 그 결과로 나온 데이터를 화면에 생성되도록 뷰를 선택하여 전달함. 
  • 전체적인 과정의 흐름을 제어함. 

---

 MVC 모델의 변화

 

이러한 MVC 모델에서 시대에 따른 변화 과정이 있는데 그것을 모델 1, 모델 2, 그리고 스프링 MVC 이렇게 세가지로 나뉘게 된다. 그렇다면 하나씩 따져보면서 어떻게 변화를 했는지 보도록 하자. 

 

모델 1

 

화면의 기능과 비즈니스 로직 처리를 하나의 JSP 페이지에서 개발하는 방법을 모델1 방식이라고 함. 클라이언트에서 입력값과 함께 요청이 들어오면 JSP 페이지는 자신이 작성한 자바빈을 이용해서 데이터를 처리하고 그에 대한 결과를 클라이언트에 출력함. 

 

 

하나의 페이지에서 view와 controller의 역할을 처리하고 있음.

 

여기서 헷갈리지 말아야하는 점은 모델1 방식이라고 하여서 서블릿(Controller)이 없는 구조라고 이해하면 안되는 것이다. 톰캣 서버 즉 WAS(Web Application Server)가 구동이 되면 알아서 서블릿(Controller)과 뷰를 구분하고 작동 시키고 있음. 

 

이러한 모델1 방식은 구조가 단순하기 때문에 개발하기에는 매우 쉽다. (뷰에서 자바언어 그대로 사용하기 때문임) 하지만 복잡한 페이지를 작성하면서 더욱 읽기가 어려워지고 난해한 코드들이 보이기 시작하면서 점점 사라지는 추세이다. 

 

모델 2

 

모델 2는 모델 1의 단점을 보완하기 위해 어플리케이션을 개발 할 때 화면기능, 요청/응답처리, 비즈니스 로직을 각각 분리하여 구현하는 것을 말한다. 

 

 

여기서 서블릿(controller)과 JSP(view)의 역할이 완전히 구분이 되기 시작함. 각각의 특징은 아래와 같음.

 

• 서블릿
  • 자바 코드를 그대로 이용 가능하고 상속이나 인터페이스 처리도 가능함. 
  • HTTP 로 전달된 메세지를 구성하는 HTML을 처리할 때 상당한 코드를 작성해야하는 어려움이 있음.
• JSP 
  • 반대로 HTML 코드를 바로 사용할 수 있어 HTTP 문서 작성에는 적합함. 
  • 자바 코드를 재사용하는 문제나 자바 코드와 HTML이 혼재하는 문제가 있음. 

 

위와 같은 특징으로 JSP를 이용하여 만들어진 View는 톰캣을 통해서 브라우저로 전송되어 클라이언트에게 보여짐. 

 

스프링 MVC

 

기존에 있는 Model-View-Controller를 좀 더 구분하여 처리 할 수 있게 만들어진 것이 스프링 MVC 모델이다. 기존과 가장 큰 차이점이 있다면 바로 Dispatcher-Servlet이다.

 

Dispatcher-Servlet

dispatch의 영어 사전적의미는 "보내다"를 가지고 있음. 이러한 단어를 포함하고 있는 Dispatcher-Servlet은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임하는 프론트 컨트롤러(Front-Controller) 라고 정의 됨. 

 

Dispatcher-Servlet은 우리가 따로 구현하는 것이 아닌 WAS 즉, 톰캣에서 해당 업무를 대신해주고 있다. 여기서 WAS 는 MVC 모델보다 더 큰 개념으로 제일 최상위 영역이라고 생각하면 된다. 

 

 

Dispatcher-Servlet (Front-Controller)

 

Dispatcher-Servlet의 업무는 핸들러로부터 받은 정보를 통해 다음 역할을 담당하는 분야에 요청에 하는 업무를 담당하는 것이다. 즉, 중앙제어 역할을 하고 있다. 

 

• 디스패처 서블릿의 장점
  • Dispatcher-Servlet이 생기면서 web.xml의 역할이 상당히 줄어 들었음. 
  • 이전의 방식은 모든 Url 맵핑을 web.xml에 적어야 했지만 이제는 알아서 찾아주는 역할을 대신함. 

 

공부하면서 추가적으로 알게된 내용은 Dispatcher-Servlet은 정적 자원 요청도 모두 가로채는 문제가 생겨 정적자원을 불러오지 못하는 현상이 발생하였다고 함. (HTML, CSS, JavsScript) 

 

이러한 부분을 해결하기 위해서 1차적으로 Controller를 찾을 수 없을 때, 2차적으로 설정된 자원 경로를 탐색하여 자원을 탐색하는 것으로 변경하였다고 함. 

 

Dispatcher-Servlet의 흐름

 

 

전체적인 흐름과 설명

 

1. 클라이언트로부터 들어온 요청을 Dispatcher-Servlet이 받음
2. Dispatcher-Servlet은 적절한 Controller를 선택하는 작업을 HandlerMapping에게 맡기고,  HandlerMapping은 요청된 URL에 Mapping 된 Controller를 선택하여 다시 Dispatcher-Servlet에게 반환.
3. Dispatcher-Servlet은 Cotroller의 business logic을 수행하는 작업을 HandelerAdapter로 전달.
4. HandlerAdapter는 Controller의 business logic 프로세스를 호출한다.
5. Controller는 business logic을 실행하고 처리결과를 Model에 저장하며, View의 이름을 HandlerAdapter에 반환한다.
6. DispatcherServlet은 5번에서 전달받은 이름을 가진 View를 찾는 작업을 ViewResolver에 전달하고, ViewResolver는 View 이름에 해당되는 jsp 파일의 이름과 경로(view)를 반환한다.
7. DispatcherServlet은 반환된 View에 Rendering 프로세스를 전달한다.
8. View는 모델 데이터를 Rendering하고 응답을 반환한다.

 

PRG패턴 (Post-Redirect-GET)

 

한 발짝 더 나아가서, 기본적으로 사용자가 Post 요청을 하면 Controller에서 다시 Get 요청을 한번 더 하여 클라이언트에게 보여주는 방식으로 진행 되고 있음. (Controller가 자신에게 한번 더 Get 요청을 하고 있다고 생각하면 됨.)이러한 패턴을 PRG 패턴이라고 함. 

 

PRG패턴의 흐름

• 사용자는 컨트롤러에 원하는 작업을 POST방식으로 처리하기를 요청
• POST방식을 컨트롤러에서 처리하고 브라우저는 다른 경로로 이동(GET) 하라는 응답(Redirect)
• 브라우저는 GET방식으로 이동