MVC 패턴, Dispatcher-Servlet 정리

Model : 데이터, 비즈니스 로직을 처리하는 부분(DAO, DTO, Service 등)

View : 비즈니스 로직 처리 결과가 유저에게 보여지는 부분, 즉 유저 인터페이스. (html, jsp 등)

Controller : Model과 View 의 통신매체, 연결해주는 부분

 

각 구성요소가 고유한 기능을 담당할 수 있게 구분한 디자인 패턴이다.

 

 

MVC 패턴은 단순히 Model, View, Controller 만 기술되어 있지만 사실 그전에 Dispatcher-Servlet, Handler Adapter, View Resolver 등 클라이언트의 요청에 응답하기 위해서 일하는 다양한 것들이 있다.

 

 

1. 클라이언트의 요청을 디스패처 서블릿이 받음
2. 요청 정보를 통해 요청을 위임할 컨트롤러를 찾음
3. 요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달함
4. 핸들러 어댑터가 컨트롤러로 요청을 위임함
5. 비지니스 로직을 처리함
6. 컨트롤러가 반환값을 반환함
7. HandlerAdapter가 반환값을 처리함
8. 서버의 응답을 클라이언트로 반환함

 

 

>> 위 순서에 대한 부연 설명

1. Dispatcher-Servlet

HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller).

클라이언트로부터 어떠한 요청이 오면 Tomcat(톰캣)과 같은 서블릿 컨테이너가 요청을 받게 됩니다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 됩니다. 그러면 디스패처 서블릿은 공통적인 작업을 먼저 처리한 후에 해당 요청을 처리해야 하는 컨트롤러를 찾아서 작업을 위임합니다.

 

 

공식문서>>

"Spring MVC는 중앙 서블릿인 DispatcherServlet이 요청 처리를 위한 공유 알고리즘을 제공하고 실제 작업은 구성 가능한 위임 구성 요소에 의해 수행되는 전면 컨트롤러 패턴을 중심으로 설계되었습니다."

 

 

 

3. 요청을 컨트롤러로 위임할 핸들러 어댑터를 찾아서 전달함

디스패처 서블릿은 컨트롤러로 요청을 직접 위임하는 것이 아니라 HandlerAdapter를 통해 컨트롤러로 요청을 위임합니다. 

이때 어댑터 인터페이스를 통해 컨트롤러를 호출하는 이유는 컨트롤러의 구현 방식이 다양하기 때문입니다. 최근에는 @Controller에  @RequestMapping 관련 어노테이션을 사용해 컨트롤러 클래스를 주로 작성하지만, Controller 인터페이스를 구현하여 컨트롤러 클래스를 작성할 수도 있습니다. 스프링은 HandlerAdapter라는 어댑터 인터페이스를 통해 어댑터 패턴을 적용함으로써 컨트롤러의 구현 방식에 상관없이 요청을 위임할 수 있는 것입니다.

 

HandlerMapping의 목적은 handler method를 URL에 매핑하는 것입니다. 이렇게 하면 디스패치 서블릿이 요청을 처리할 때 이를 호출할 수 있습니다.

실제로 Dispatcher Servlet은 HandlerAdapter를 사용하여 메서드를 호출합니다.

 

 

 

https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#spring-web

Web on Servlet Stack

https://mangkyu.tistory.com/18

[Spring] Dispatcher-Servlet(디스패처 서블릿)이란? 디스패처 서블릿의 개념과 동작 과정