Spring MVC 구조

Spring MVC 전체 구조

Spring MVC 는 이 전에 직접 만들었던 MVC 구조와 매우 흡사합니다.

이름만 조금 다를 뿐 구조와 로직을 동일합니다.

직접 만든 MVC 프레임워크

Spring MVC

이름만 바뀌었을 뿐 각 클래스의 역할은 동일합니다

• Front-Controller ➣ DispatcherServlet
• handlerMappingMap ➣ HandlerMapping
• MyhandlerAdapter ➣ HandlerAdapter
• ModelView ➣ ModelAndView
• viewResolver ➣ ViewResolver
• MyView ➣ View

이 전 포스팅에서 만들었던 MVC 구조를 잘 기억하면서 각 클래스들의 역할을 기억하면 됩니다.

 

Spring MVC 또한 프론트 컨트롤러 패턴으로 구현되어 있는데요. 

Spring MVC의 프론트 컨트롤러가 바로 DispatcherServlet입니다. 

이 디스패쳐 서블릿이 스프링 MVC의 핵심입니다.

 

우선 DispatcherServlet을 살펴보겠습니다.

 

DispatcherServlet 서블릿 등록

 

DistpatcherServlet은 부모 클래스인 HttpServlet을 상속받아 사용하고, 서블릿으로 동작합니다.

HttpServlet ▷ DispatcherServlet

서블릿 상속관계

• DispatcherServlet ➣ FrameworkServlet ➣ HttpServletBean ➣ HttpServlet 

스프링 부트는 DispatcherServlet을 서블릿으로 자동으로 등록하고 모든 경로 urlPatterns="/"에 대해 매핑합니다.

 

요청 흐름

1. 서블릿이 호출되면 HttpServlet이 제공하는 service()가 호출됩니다.
2. 스프링 MVC는 DispatcherServlet의 부모인 FrameworkServlet에서 service()를 오버라이드 해뒀습니다.
3. 따라서 FrameworkServlet.service()를 시작으로 여러 메소드가 호출되면서 DispatcherServlet.doDispatch()가 호출됩니다.

서블릿 호출 ➣ HttpServlet.service() 호출 ➣ FrameworkServlet.service() 호출 ➣ DispatcherServlet.doDispatch()   

 

DispatcherServlet.doDispatch() 코드를 분석해보겠습니다.

protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
   HttpServletRequest processedRequest = request;
   HandlerExecutionChain mappedHandler = null;
   boolean multipartRequestParsed = false;

   WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);

   try {
      ModelAndView mv = null;
      Exception dispatchException = null;

      try {
         processedRequest = checkMultipart(request);
         multipartRequestParsed = (processedRequest != request);

         // Determine handler for the current request.
         mappedHandler = getHandler(processedRequest);
         if (mappedHandler == null) {
            noHandlerFound(processedRequest, response);
            return;
         }

         // Determine handler adapter for the current request.
         HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

         // Process last-modified header, if supported by the handler.
         String method = request.getMethod();
         boolean isGet = "GET".equals(method);
         if (isGet || "HEAD".equals(method)) {
            long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
            if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
               return;
            }
         }

         if (!mappedHandler.applyPreHandle(processedRequest, response)) {
            return;
         }

         // Actually invoke the handler.
         mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

         if (asyncManager.isConcurrentHandlingStarted()) {
            return;
         }

         applyDefaultViewName(processedRequest, mv);
         mappedHandler.applyPostHandle(processedRequest, response, mv);
      }
      catch (Exception ex) {
         dispatchException = ex;
      }
      catch (Throwable err) {
         // As of 4.3, we're processing Errors thrown from handler methods as well,
         // making them available for @ExceptionHandler methods and other scenarios.
         dispatchException = new NestedServletException("Handler dispatch failed", err);
      }
      processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
   }
   catch (Exception ex) {
      triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
   }
   catch (Throwable err) {
      triggerAfterCompletion(processedRequest, response, mappedHandler,
            new NestedServletException("Handler processing failed", err));
   }
   finally {
      if (asyncManager.isConcurrentHandlingStarted()) {
         // Instead of postHandle and afterCompletion
         if (mappedHandler != null) {
            mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
         }
      }
      else {
         // Clean up any resources used by a multipart request.
         if (multipartRequestParsed) {
            cleanupMultipart(processedRequest);
         }
      }
   }
}

 

1. 핸들러 조회

// Determine handler for the current request.
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
   noHandlerFound(processedRequest, response);
   return;
}

request에 매핑되는 핸들러(컨트롤러)가 있는지 조회합니다. 

 

2. 어댑터 조회

// Determine handler adapter for the current request.
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

1에서 조회한 핸들러를 처리할 수 있는 어댑터가 있는지 조회합니다.

 

3. 어댑터 실행 ➣ ModelAndView 리턴 

// Actually invoke the handler.
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

 

4. 리턴된 ModelAndView를 이용해 processDispatchResult 메소드 실행

processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);

 

processDispatchResult 메소드 ➣ render 메소드 호출 

private void processDispatchResult(HttpServletRequest request, HttpServletResponse response,
      @Nullable HandlerExecutionChain mappedHandler, @Nullable ModelAndView mv,
      @Nullable Exception exception) throws Exception {
      
      render(mv, request, response);
  }

 

render 메소드

protected void render(ModelAndView mv, HttpServletRequest request, HttpServletResponse response) throws Exception 
{
    View view;
    String viewName = mv.getViewName(); 
    
    view = resolveViewName(viewName, mv.getModelInternal(), locale, request);
   
    view.render(mv.getModelInternal(), request, response);

}

5. 뷰 리졸버를 통해 뷰 찾고 View 반환

view = resolveViewName(viewName, mv.getModelInternal(), locale, request);

6. View 렌더링

view.render(mv.getModelInternal(), request, response);

 

동작 순서

1. 핸들러 조회 : 핸들러 매핑을 통해 요청 URL에 대해 매핑된 컨트롤러(핸들러) 조회

2. 핸들러 어댑터 조회 : 조회한 핸들러를 실행할 수 있는 어댑터 조회

3. 핸들러 어댑터 실행 : 어댑터 실행 

4. 핸들러 실행 : 핸들러 어댑터가 핸들러 실행 

5. ModelAndView 반환 : 핸들러가 리턴하는 정보를 ModelAndView에 담아 리턴

6. viewResolver 호출  :  뷰 리졸버를 찾고 실행 

 JSP의 경우 InternalResourceViewResolver가 자동 등록되고 사용됩니다. 뒤에서 다루겠습니다. 우선 패스

7. View 반환 : 뷰 리졸버가 뷰의 논리 이름을 물리 이름으로 바꿔서 뷰 객체를 리턴합니다.

8. 뷰 렌더링 : 뷰를 통해서 뷰를 렌더링 합니다.

 

 

인터페이스 살펴보기

Spring MVC의 큰 강점 : DispatcherServlet 코드의 변경 없이 원하는 기능을 변경하거나 확장할 수 있습니다.

이 인터페이스들을 구현해서 DispatcherServlet에 등록만하면 커스텀 컨트롤러를 만들 수 있습니다.

 

주요 인터페이스 목록

1. 핸들러 매핑: org.springframework.web.servlet.HandlerMapping
2. 핸들러 어댑터: org.springframework.web.servlet.HandlerAdapter
3. 뷰 리졸버: org.springframework.web.servlet.ViewResolver
4. 뷰: org.springframework.web.servlet.View

 

<정리>

 

1. 스프링 MVC는 코드 분량이 매우 많고 복잡, 내부구조 다 파악하는 것은 무리

2. 스프링 MVC는 수많은 기능들이 구현되어 있어 해당 기능을 확장하거나 커스텀 컨트롤러를 만들 일은 없음.

3. 그래도 핵심동작 방식을 알아두면 디버깅하거나 확장 포인트가 필요할 때 어떤 부분을 확장해야 하는지 감을 잡을 수 있음

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의

https://catsbi.oopy.io/f52511f3-1455-4a01-b8b7-f10875895d5b

스프링 MVC - 구조 이해