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

스프링 MVC 1편의 강의 내용을 정리한 포스팅입니다.

---

스프링 MVC 전체 구조

구조

이전에 직접 만들었던 MVC 프레임워크 구조와 거의 같은 형태를 가지고 있다.

스프링 MVC도 프론트 컨트롤러 패턴으로 구현되어 있는데, 여기서의 프론트 컨트롤러는 디스패처 서블릿(Dispatcher Servlet)이다.

디스패처 서블릿은 HttpServlet을 상속받으며, 서블릿으로 동작한다. 또한 스프링 부트는 디스패처 서블릿을 서블릿으로 자동 등록함과 동시에 모든 경로에 대해 매핑되도록 한다. 이때의 urlPatterns 속성 값은 "/"이기 때문에, 부가적으로 등록한 서블릿이 더 자세한 경로를 가지고 있다면 우선순위에 따라서 해당 서블릿도 함께 동작하게 되는 것이다.

 

 

동작 순서

서블릿이 호출되면 부모 클래스인 HttpServlet이 제공하는 service()가 호출됨에 따라 DispatcherServlet.doDispatch()가 호출되는데, 해당 메서드의 흐름을 정리하면 다음과 같다.

1. 핸들러 조회 - 핸들러 매핑을 통해 요청 URL에 매핑된 핸들러를 조회한다.

2. 핸들러 어댑터 조회

3. 핸들러 어댑터 실행

4. 핸들러 실행 - 핸들러 어댑터가 실제 핸들러를 실행한다.

5. ModelAndView 반환 - 핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해서 반환한다.

6. 뷰 리졸버 호출

7. 뷰 반환 - 뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 뷰 객체를 반환한다.

8. 뷰 렌더링

 

 

스프링 MVC와 인터페이스

스프링 MVC의 큰 강점은 디스패처 서블릿의 코드 변경 없이 기능을 원하는 대로 변경하거나 확장할 수 있다는 점이다.

위의 흐름에 해당하는 기능들은 대부분 확장 가능한 인터페이스로 구현되어 있기 때문에 해당 인터페이스들만 구현해서 디스패처 서블릿에 등록하면 직접 컨트롤러를 만들 수도 있는 것이다.

 

 

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

컨트롤러 호출

컨트롤러가 호출되기 위해서는 핸들러 매핑과 핸들러 어댑터가 필요한데, 스프링에서는 두 기능을 대부분 구현해 두었다.

 

1. 핸들러 매핑(HandlerMapping)

요청과 핸들러 객체 간의 매핑을 정의하는 인터페이스로, 핸들러 매핑을 통해 특정 컨트롤러를 찾을 수 있다.

스프링 부트가 자동 등록하는 핸들러 매핑 중 대표적인 구현체는 RequestMappingHandlerMapping과 BeanNameUrlHandlerMapping인데 전자는 @RequestMapping으로부터 요청 매핑 정보를 생성하고, 후자는 스프링 빈의 이름을 가진 핸들러를 찾는다.

RequestMappingHandlerMapping이 우선순위에서 가장 앞서기 때문에, 해당 단계에서 매핑 정보를 찾지 못했다면 다음 우선순위를 가진 핸들러 매핑 구현체를 실행한다.

 

2. 핸들러 어댑터(HandlerAdapter)

특정 핸들러 객체에 의해 종속되지 않도록 확장 가능하게 설계된 인터페이스로, 핸들러 매핑을 통해 찾은 핸들러를 실행할 수 있도록 한다.

스프링 부트가 자동 등록하는 핸들러 어댑터 중 대표적인 구현체는 RequestMappingHandlerAdapter, HttpRequestHandlerAdapter, SimpleControllerHandlerAdapter가 있다.

RequestMappingHandlerAdapter는 핸들러 어댑터 구현을 위한 클래스인 AbstractHandlerMethodAdapter를 상속받았으며 @RequestMapping 사용 시 이용되는 클래스이다.

 

HttpRequestHandlerAdapter는 HttpRequestHandler를 처리하는 클래스이며, SimpleControllerHandlerAdapter는 과거에 사용되던 Controller 인터페이스(!= @Controller)를 처리하는 클래스이다.

 

 

동작 방식

앞서 살펴보았던 MVC 과정 중 핸들러 조회 - 핸들러 어댑터 조회 - 핸들러 어댑터 실행 단계를 거친다.

 

 

뷰 리졸버

뷰 리졸버 호출

프론트 컨트롤러인 디스패처 서블릿이 핸들러 어댑터로부터 ModelAndView를 반환받으면, 디스패처 서블릿은 이름을 가지고 뷰를 찾아낼 수 있는 뷰 리졸버를 호출하여 뷰를 반환받는다. 뷰 리졸버 역시 스프링 부트가 자동 등록해 놓은 구현체들이 존재하는데, 대표적인 구현체는 BeanNameViewResolver, InternalResourceViewResolver가 있다.

전자는 빈 이름으로 뷰를 찾아 반환하며, 후자는 서블릿이나 JSP와 같은 리소스를 처리할 수 있는 뷰를 생성해 반환한다.

만약 전자를 호출했는데 뷰를 찾지 못했다면 후자를 호출한다.

 

 

동작 방식

핸들러 어댑터를 통해 얻은 논리 뷰 이름을 가지고 뷰 리졸버를 호출하는데, 이때 뷰가 존재할 경우 해당 뷰를 반환하지만 찾지 못한 경우 InternalResourceViewResolver가 호출되어 포워드 InternalResourceView를 반환한다.

디스패처 서블릿은 반환된 뷰를 render()라는 메서드를 통해 실행하는데, 만약 뷰의 종류가 InternalResourceView이면서 forward() 메서드를 처리할 수 있다면 해당 메서드를 통해 JSP를 실행하고, 적합한 뷰 리졸버를 찾지 못한 경우라면 InternalResourceViewResolver를 디폴트 값으로 설정하게 된다.

 

 

 

스프링 MVC의 편의 기능

Model 파라미터

컨트롤러 생성 시 파라미터로 인터페이스인 Model을 받을 수 있어 addAttribute()와 같은 메서드를 이용할 수 있다.

 

뷰 이름 직접 반환

뷰의 논리 이름을 반환할 수 있다.

 

@RequestParam 사용

HTTP 요청 파라미터를 @RequestParam을 통해 받을 수 있는데, @RequestParam("userName")은 request.getParameter("userName")과 거의 유사한 효과를 가진다.

GET 쿼리 파라미터와 POST 폼 방식에서도 지원되는 기능이다.

 

@RequestMapping - HTTP 메소드 지정

@RequestMapping을 통해 URL을 매핑함과 동시에 HTTP 메소드도 함께 구분할 수 있는데, 다음과 같이 이용할 수 있다.

@RequestMapping(value = "new-form", method = RequestMethod.GET)

해당 기능은 @GetMapping, @PostMapping 등 각 HTTP 메소드에 해당하는 애노테이션을 이용함으로써 보다 간편하게 이용할 수 있다.

@GetMapping("/new-form")

@GetMapping 애노테이션의 내부 코드를 보면 @RequestMapping 애노테이션이 선언되어 있음을 확인할 수 있다.