스프링 MVC의 구조 이해(1) - DispatcherServlet, 핸들러 매핑과 핸들러 어댑터, 뷰 리졸버

현재까지 만든 프레임워크와 스프링 MVC의 비교

직접 만든 프레임워크 스프링 MVC 비교

• FrontController → DispatcherServlet
• handlerMappingMap → HandlerMapping
• MyHandlerAdapter → HandlerAdapter
• ModelView → ModelAndView
• viewResolver → ViewResolver
• MyView → View

DispatcherServlet의 구조

• DispatcherServlet도 HttpServlet을 상속받아서 사용하는 서블릿
  • DispatcherServlet → FrameworkServlet → HttpServletBean → HttpServlet
• 스프링부트는 DispatcherServlet을 서블릿으로 자동 등록하면서 모든 경로(urlpatterns=”/”)에 대해서 매핑한다.

요청 흐름

• 서블릿이 호출되면 HttpServlet의 Service() 메서드가 호출된다.
• 스프링 MVC는 FrameworkServlet에서 service()를 오버라이드 → DispatcherServlet이 상속
• FrameworkServlet.service() 을 시작으로 DispacherServlet.doDispatch() 가 호출되면서 비즈니스 로직이 시작된다. → 스프링 MVC의 핵심 동작은 doDispatch()에 기술 된다.

DispatcherServlet.doDispatch()

• 핵심 동작 코드만 기술
• 예외처리, 인터셉터 기능은 제외하고 간단하게 정리

protected void doDispatch(HttpServletRequest request, HttpServletResponse
            response) throws Exception {
        HttpServletRequest processedRequest = request;
        HandlerExecutionChain mappedHandler = null;
        ModelAndView mv = null;

    // 1. 핸들러 조회
        mappedHandler = getHandler(processedRequest);
        if (mappedHandler == null) { noHandlerFound(processedRequest, response);
            return;
        }

    // 2. 핸들러 어댑터 조회 - 핸들러를 처리할 수 있는 어댑터
        HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

    // 3. 핸들러 어댑터 실행 -> 4. 핸들러 어댑터를 통해 핸들러 실행 -> 5. ModelAndView 반환
        mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
        processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
    }
    private void processDispatchResult(HttpServletRequest request, HttpServletResponse response, HandlerExecutionChain mappedHandler, ModelAndViewmv, Exception exception) throws Exception {
    // 뷰 렌더링 호출
        render(mv, request, response);
    }
    protected void render(ModelAndView mv, HttpServletRequest request,
                          HttpServletResponse response) throws Exception {
        View view;
        String viewName = mv.getViewName();

    // 6. 뷰 리졸버를 통해서 뷰 찾기, 7. View 반환
        view = resolveViewName(viewName, mv.getModelInternal(), locale, request);

    // 8. 뷰 렌더링
        view.render(mv.getModelInternal(), request, response);
    }

1. 핸들러 조회 : 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러(컨트롤러)를 조회한다.
2. 핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회
3. 핸들러 어댑터 실행
4. 핸들러 실행 : 핸들러 어댑터에서 실제 핸들러를 실행 ha.handle(processedRequest, response, mappedHandler.getHandler());
5. ModelAndView 반환 : 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView 형태로 반환
6. viewResolver 호출 : 뷰 리졸버를 찾고 실행
7. view 반환 : 뷰 리졸버는 뷰의 논리이름을 물리이름으로 바꾸고, 뷰 객체를 반환한다.
   • JSP의 경우 InternalResourceView(JstlView) 를 반환하는데, 내부에 forward() 로직이 있다.
8. 뷰 렌더링 : 뷰를 통해서 렌더링 한다.

정리

• 스프링 MVC는 분량도 많고, 복잡해서 내부 핵심 구조만 잘 파악해도 충분
  • 대부분의 기능이 이미 구현되어 있기때문에, 직접 기능을 확장하거나, 나만의 컨트롤러를 만들 일이 거의 없기 때문
• 향후 문제가 발생했을때, 어떤 부분에서 문제가 발생했는지 파악 가능하도록 이해하는 것이 목표

핸들러 매핑 & 핸들러 어댑터

• 지금은 사용하지 않는, 과거의 Controller 인터페이스로 핸들러 매핑과 어댑터를 이해해 보자

OldController가 호출 되는 과정

@Component("/springmvc/old-controller")  //컴포넌트 등록
public class OldController implements Controller { //Controller인터페이스 impl, 현재는 @Controller로 모든 기능이 대체됨
    @Override
    public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
        return new ModelAndView("new-form");
    }
}

• 해당 핸들러(컨트롤러)가 호출되려면 2가지가 필요
  • HandlerMapping(핸들러 매핑) : url경로를 처리 할 수 있는 핸들러 매핑을 찾고 핸들러 반환
    → ex) 스프링 빈의 이름으로 핸들러를 찾을 수 있는 핸들러 매핑이 필요
  • HandlerAdapter(핸들러 어댑터) : 핸들러 매핑을 통해서 찾은 핸들러를 실행 하는 핸들러 어댑터가 필요
    → ex) Controller 인터페이스를 실행 할 수 있는 핸들러 어댑터를 찾고 실행

HandlerMapping & HandlerAdapter의 처리 우선순위

//Handler Mapping
0 = RequestMappingHandlerMapping : 애노테이션 기반의 컨트롤러인 @RequestMapping에서사용
1 = BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러를 찾는다.

//Handler Adapter
0 = RequestMappingHandlerAdapter : 애노테이션 기반의 컨트롤러인 @RequestMapping에서사용
1 = HttpRequestHandlerAdapter : HttpRequestHandler 처리
2 = SimpleControllerHandlerAdapter : Controller 인터페이스(애노테이션X, 과거에 사용) 처리

동작 순서

1. 핸들러 매핑으로 핸들러 조회
   • HandlerMapping을 순서대로 실행해서 핸들러 탐색
   • 이 경우 빈 이름으로 핸들러를 찾아야 하기 때문에 BeanNameUrlHandlerMapping을 실행, OldController 반환
2. 핸들러 어댑터 조회
   • HandlerAdapter의 supports()를 순서대로 호출
   • SimpleControllerHandlerAdapter 가 Controller 인터페이스를 지원하므로 대상이 된다.
3. 핸들러 어댑터 실행
   • 위에서 찾은 핸들러인 SimpleControllerHandlerAdapter 를 통해 OldController를 내부에서 실행
   • ModelAndView 객체 반환

정리

• OldController를 실행하면서 사용된 객체
  1. 핸들러 매핑 = BeanNameUrlHandlerMapping
  2. 핸들러 어답터 = SimpleControllerHandlerAdapter

뷰 리졸버(viewResolver)

• 논리 뷰 이름을 실제 물리 주소로 바꿔주는 역할

application.properties

spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp

→ 스프링 부트는 JSP사용을 위해서 InternalResourceViewResolver 라는 뷰 리졸버를 자동으로 등록

→ application.properties 에 등록한 spring.mvc.view.prefix , spring.mvc.view.suffix 설정 정보를 사용해서 등록

스프링 부트가 자동 등록하는 뷰 리졸버

1 = BeanNameViewResolver : 빈 이름으로 뷰를 찾아서 반환한다. (예: 엑셀 파일 생성 기능에 사용)
2 = InternalResourceViewResolver : JSP를 처리할 수 있는 뷰를 반환한다.

동작 순서

1. 핸들러 어댑터 호출
   • 핸들러 어댑터를 통해 new-form 이라는 논리 뷰 이름을 획득
2. ViewResolver 호출
   • new-form이라는 뷰 이름으로 viewResolver를 순서대로 호출
   • BeanNameViewResolver 에 등록된 new-form 뷰는 없으므로 InternalResourceViewResolver 가 호출된다.
3. InternalResourceViewResolver
   • 뷰 리졸버는 InternalResourceView 를 반환한다
4. view.render()
   • view.render() 가 호출되고 InternalResourceView 는 forward() 를 사용해서 JSP를 실행한다.