[Spring] 스프링 MVC - 구조 이해

안녕하세요 이번 포스팅은 저희 그동안 힘겹게 만들었던 프레임워크와 스프링 MVC를 비교해보겠습니다!!

 

 

 

DispatcherServlet 구조 살펴보기

 

1. 스프링 MVC도 프론트 컨트롤러 패턴으로 구현되어 있습니다.

2. 스프링 MVC의 프론트 컨트롤러가 바로 디스패처 서블릿(DispatcherServlet)입니다.

3. 그리고 이 디스패처 서블릿이 바로 스프링 MVC의 핵심입니다.

 

DispatcherServlet 서블릿 등록

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

  -> DispatcherServlet -> FrameworkServlet -> HttpServletBean -> HttpServlet

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

  -> 참고 : 더 자세한 경로가 우선순위가 높습니다. 그래서 기존에 등록한 서블릿도 함께 동작합니다.

 

 

요청 흐름

서블릿이 호출되면 HttpServlet이 제공하는 service()가 호출됩니다.

스프링 MVC는 DispatcherServlet의 부모인 FrameworkServlet에서 service()를 오버라이드 해두었습니다.

FrameworkServlet.service()를 시작으로 여러 메서드가 호출되면서 DispatcherServlet.doDispatch()가 호출됩니다.

 

지금부터 DispatcherServlet의 핵심인 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, ModelAndView 
    			mv, 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);
	}

 

 

 

동작 순서

핸들러 조회 : 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러를 조회합니다.

핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회합니다.

핸들러 어댑터 실행 : 핸들러 어댑터를 실행합니다.

핸들러 실행 : 핸들러 어댑터가 실제 핸들러를 실행합니다.

ModelAndView 반환 : 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해서 반환합니다.

viewResolver 호출 : 뷰 리졸버를 찾고 실행합니다. - JSP의 경우 InternalResourceViewReolsver가 자동 등록되고 사용됩니다.

View반환 : 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고 렌더링 역할을 담당하는 뷰 객체를 반환합니다.

JSP의 경우 InternalResourceView(JstlView)를 반환하는데, 내부에 forward() 로직이 있습니다.

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

 

 

인터페이스 살펴보기

스프링 MVC의 큰 강점은 DispatcherSerlvwet 코드의 변경 없이, 원하는 기능을 변경하거나 확장할 수 있다는 점입니다. 지금까지 설명한 대부분을 확장 가능할 수 있게 인터페이스로 제공합니다.

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

 

 

정리

스프링 MVC는 코드 분량도 매우 많고, 복잡해서 내부 구조를 다 파악하는 것은 쉽지 않습니다.

사실 해당 기능을 직접 확장하거나 나만의 컨트롤러를 만드는 일은 없으므로 걱정하지 않아도 됩니다.

왜냐하면 스프링 MVC는 전 세계 수많은 개발자들의 요구사항에 맞추어 기능을 계속 확장 왔고, 그래서 여러분이 웹 애플리케이션을 만들 때 필요로 하는 대부분의 기능이 이미 다 구현되어 있습니다. 그래도 이렇게 핵심 동작 방식을 알아두어야 향후 문제가 발생했을 때 어떤 부분에서 문제가 발생했는지 쉽게 파악하고, 문제를 해결할 수 있습니다. 그리고 확장 포인트가 필요할 때, 어떤 부분을 확장해야 할지 감을 잡을 수 있습니다. 우리가 지금까지 함께 개발한 MVC 프레임워크와 유사한 구조여서 이해하기 어렵지 않았을 것이다.

 

다음 포스팅에서는 스프링의 핸들러 매핑과 핸들러 어댑터를 알아보겠습니다