[Spring] 스프링 MVC 패턴 개요

스프링 MVC 패턴 개요

1. 스프링 MVC 패턴

‘MVC(Model View Controller)’란 비즈니스 규칙은 표현하는 도메인 모델(Model)과 프레젠테이션을 표현하는 View를 분리하기 위하여 양측 사이에 컨트롤러를 배치하도록 설계한 디자인 패턴이다.

‘스프링 MVC ’ 란 스프링이 제공하는 웹 어플리케이션 구축 전용의 MVC 프레임워크이다. 스프링 MVC를 이용함으로써 웹 어플리케이션의 Model, View, Controller 사이의 의존 관계를 DI 컨테이너에서 관리하고 통일된 유연한 웹 어플리케이션을 구축할 수 있다.

2. 스프링 MVC 처리 흐름

스프링 MVC는 스트릿츠 등 웹 어플리케이션 프레임워크와 동일하게 Front Controller 패턴을 채용하고 있다. 

FrontController 패턴이란 핸들러 오브젝트를 매개로 하여 요청을 분배함으로써 요청을 통합하고, 요청에 대한 통일된 처리를 기술할수 있도록하기 위한 패턴이다.

다음 그림에서 보듯이 브라우저로부터 송신된 요청은 모두 스프링 MVC에 의해 제공되는DispatherServlet 클래스에 의해 관리되고 있다.

웹 브라우저로부터의 요청(Request)은 DispatcherServlet 인스턴스로 송신된다. 요청을 받은 DispatcherServlet 인스턴스는 어플리케이션 안에서 공통 처리를 실행한 다음, requestURL 고유의 처리를 실행하는 Request 컨트롤러(Controller 인스턴스)를 호출한다. 일반적으로 Request 컨트롤러는 처리 단위 별로 개발자가 작성하기 때문에 DispatcherServlet 인스턴스는 지정된 RequestURL이 어느 Request 컨트롤러에 맵핑되어 있는기를 알아야 한다. 그러나 DispatcherServlet은 어플리케이션에서 하나의 인스턴스일 뿐 랩핑 정보를 관리하는 기능을 갖고 있지 않는다. 

RequestURL과 Request 컨트롤러의 맵핑을 관리하고 있는 것은 HanadlerMapping 인스턴스이다. DispatcherSerγlet 인스턴스 HandlerMapping 인스턴스를 참조하여 HandlerMapping 인스턴스로부터 반환된 Controller 인스턴스로 처리를 전달한다. 처리가 전달된 Controller 인스턴스는 필요한 비즈니스 로직을 호출하여 처리 결과(모델)와 이동할 View 정보를 DispatcherServlet에 반환한다. 이들의 정보(모델과 View)는 스프링MVC가 제공하는 ModeAndView 인스턴스로 취급된다. 

그리고 Controller 인스턴스로부터 반환된 View는 논리 정보이기 때문에 DispatcherServlet 인스턴스는 그 View의 실체를 ViewResolver 인스턴스에 문의한다. DispatcherServlet은 ViewResolver 인스턴스에 의해 해결된 View 인스턴스에 대해 모댈을 rendering하여 처리 결과를 브라우저에 표시한다 이상이 스프링 MVC 처리의 흐름이다.

위의 그림에 있는 HandlerMapping, Controller, ViewResolver, View는 모두 스프링 MVC가 제공하는 인터페이스이다. 

그러나 인터페이스만으로는 어플리케이션이 이루어지지 않으므로 인터페이스를 구현한 클래스가 필요하다. 

하지만 어플리케이션 개발자가 각각의 인터페이스의 구현 클래스를 준비해야만 하는 것은 아니다. 스프링 MVC에는 인터페이스뿐만 아니라 각각의 인터페이스의 구현 클래스도 포함하고 있다.

통상 개발에서는 Controller를 제외한 HandlerlMapping, Viewresolver, View 인터페이스의 구현 클래스는 스프링 MVC에서 제공히는 구현 클래스를 활용하면 된다(Controller 인터페이스를 구현한 편리한 클래스도 준비되어 있다).

스프링 MVC는 이들의 구성 정보를 DI 컨테이너에서 관리하고 있다. 스프링 설정 파일을 어느 HandlerMapping의 구현 클래스를 사용할 것인지는 Controller 클래스로부터 호출할 비즈니스 로직을 연관 지음으로써 어플리케이션의 구성을 관리하면 된다.

(1) DispatcherServlet

웹 브라우저로부터 송신된 Request를 일괄적으로 관리한다 .

웹 브라우저로부터 요청은 DispatherServlet 인스턴스로 송신된다. DispatherSerlvet 인스턴스는 지정된 RequestURL이 어느 Request 컨트롤러에 맵핑되어 있는 가를 알아야 한다.

cf.) DispatherServlet 설정과 ApplicationContext 관계

DispatherServlet은 클라이언트의 요청을 중앙에서 처리하는 스프링 MVC의 핵심 구성 요소이다. 

web.xml 파일에 한 개 이상의 DispatherServlet을 설정할 수 있으며, 각 DispatherServle은  한 개의 WebApplicationContext를 갖게 된다.

또한, 각 DispatherServlet이 공유할 수 있는 빈을 설정할 수도 있다. 

DispatherServlet과 웹 어플리케이션을 위한 설정 방법 및 둘 사이의 관계에 대해서 살펴보자.

(2) HandlerMapping

- RequestURL과 Controller 클래스의 맵핑을 관리한다.

- HandlerMapping 인스턴스의 정의에 정의된 정보로부터 Controller에 해당하는 클래스(Request 컨트롤러)가 결정된다.

- BeanNameUrlHandlerMapping 클래스는 스프링 설정 파일 내에 정의된 Controller 클래스의 name 속성과 RequestURl과 맵핑하는 HandlerMapping 인터페이스의 구현 클래스이다.

- BeanNameUrlHandlerMapping 클래스는 name 속성으로 지정된 값을 그대로 context root 이하의 패스로 처리한다. 즉, 다음의 RequestURL이 웹 브라우저에서 보내졌을 경우에 여기에서 지정한 Controller 클래스가 호출되게 된다. HandlerMapping 인터페이스의 구현 클래스 중 디폴트 클래스:BeanNameUrlHandlerMapping

(3) Controller

Controller 인스턴스는 필요한 비즈니스 로직을 호출하여 처리 결과(모델)와 이동할 View 정보를 DispatherServlet에 반환된다. 

이들의 정보(모델과 view)는 스프링 MVC가 제공하는 ModelAndView 인스턴스로 취급된다. 

그리고 Controller 인스턴스로부터 반환된 View는 논리정보이기 때문에 DispatherServlet 인스턴스는 그 View의 실체를 ViewResolver 인스턴스에 문의한다. 

DispatherServlet은 ViewResolver 인스턴스에 의해 해결된 View 인스턴스에 대해 모델을 rendering하여 처리 결과를 브라우저에 표시한다. 

cf.) HandlerMapping, Controller, ViewResolver, View는 모두 스프링 MVC가 제공하는 인터페이스이다. 그러나 인터페이스만으로는 어플리케이션이 이루어지지 않으므로 인터페이스를 구현 클래스가 필요한다.

스프링 MVC에는 인터페이스뿐만 아니라 각각의 인터페이스의 구현 클래스도 포함하고 있다.

통상 개발에서는 Controller를 제외한 HandlerMapping, Viewresolver, View 인터페이스의 구현 클래스는 스프링 MVC에서 제공하는 구현 클래스를 활용하면 된다.(Controller 인터페이스를 구현한 편리한 클래스도 준비되어 있다.) 

스프링 MVC는 이들의 구성 정보를 DI 컨테이너에서 관리하고 있다.

(4) ModelAndView

1) Controller 처리 결과 후 응답할 view와 veiw에 전달할 값을 저장.

2) 생성자 

- ModelAndView(String viewName) : 응답할 view설정

- ModelAndView(String viewName, Map values) : 응답할 view와 view로 전달할 값들을 저장 한 Map 객체 

- ModelAndView(String viewName, String name, Object value) : 응답할 view이름, view로 넘길 객체의 name-value

3) 주요 메소드

- setViewName(String view) : 응답할 view이름을 설정

- addObject(String name, Object value) : view에 전달할 값을 설정 – requestScope에 설정됨

- addAllObjects(Map values) : view에 전달할 값을 Map에 name-value로 저장하여 한번에 설정 - requestScope에 설정됨

4) Redirect 방식 전송

- view이름에 redirect: 접두어 붙인다.ex) mv.setViewName(“redirect:/welcome.html”);

protected ModelAndView HandlerequestInternal(HttpServletRequest req,  HttpServletResponse res) throws Exception{

//Business Logic 처리

ModelAndView mv = new ModelAndView();      

mv.setViewName(“/hello.jsp”);

mv.addObject(“greeting”, “hello world”);

return mv;

}

(5) ViewResolver

Controller 클래스로부터 반환된 View 정보가 논리적인 View 이름일 경우에는 bean 설정파일에 정의되어 있는 ViewResolver 클래스를 이용하여 클라이언트에게 출력할 View 객체를 얻게 된다.

InternalResource ViewResolver 클래스는 Request 컨트롤러로부터 반환된 View 정보를 context root 이하의 패스로서 처리한다.

1) Controller가 넘긴 view이름을 통해 알맞은 view를 찾는 역할

- Controller는 ModelAndView 객체에 응답할 view이름을 넣어 return.

- DispatchServlet은 ViewResolver에게 응답할 view를 요청한다.

- ViewResolver는 View 이름을 이용해 알 맞는 view객체를 찾는다.

2) 다양한 ViewResolver를 SpringFramework는 제공한다.

- InternalResourceViewResolver : 뷰의 이름을 JSP, HTML등과 연동한 View를 return

- ViewResolver – Spring 설정파일에 등록한다.

Controller

ModelAndView mv = new ModelAndView();

mv.setViewName(“hello”)

위의 경우

/WEB-INF/jsp/hello.jsp 를 찾는다.

(6) View

프레젠테이션층으로의 출력 데이터를 설정한다.