04. DispatcherServlet 과 Spring MVC pattern

1. 개요 (from 전자정부표준프레임워크)

 

Spring MVC Framework의 유일한 Front Controller인 DispatcherServlet은 spring MVC의 핵심요소이다.

DispatcherServlet은 Controller로 향하는 모든 웹요청의 진입점이며, 웹요청을 처리하며 결과 데이터를 Client에게 응답한다.

 

web.xml에 DispatcherServlet 설정하기

Spring MVC Framework을 사용하기 위해서는 web.xml에 DispatcherServlet을 설정하고, DispatcherServlet이 WebApplicationContext를 생성할수 있도록 빈(Bean) 정보가 있는 파일들도 설정해주어야 한다. 

 

1-1 MVC1, MVC2 패턴의 종말

DispatcherServlet 사용으로 기존 MVC1과 MVC2패턴은 쓰이지 않는다.

 

2. 기본설정

web.xml에 아래와 같이 DispatcherServlet이 자동으로 설정된다.

	<!-- Processes application requests -->
	<servlet>
		<servlet-name>appServlet</servlet-name>
		<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
		<init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value>/WEB-INF/spring/appServlet/servlet-context.xml</param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>
		
	<servlet-mapping>
		<servlet-name>appServlet</servlet-name>
		<url-pattern>/</url-pattern>
	</servlet-mapping>

클라이언트가 해당 어플리케이션에 접근하면 접근한 URL 요청을 DispatcherServlet 이 가로챈다.

이렇게 요청을 가로챌 수 있는 이유는 web.xml 에 등록된 DispatcherServlet 의 <url-pattern>이 ‘/’ 와 같이 해당 어플을 통과하는 모든 URL로 등록했기 때문이다.

특정 URL 만 적용하고 싶다면 <url-pattern> 의 내용을 바꿔주어 범위를 변경시켜주면 된다.

 

3. HandlerMapping

• Dispatcher가 받은 요청은 HandlerMapping으로 넘어간다. 그리고 이 요청을 처리할 수 있는 Controller를 찾게 된다.

• Controller부터는 개발된 애플리케이션 영역이다. DB 연동 등 로직 처리가 이루어지고 view로 넘어간 후에 최종적으로 DispatcherServlet를 거쳐 클라이언트에 리턴된다.

 

4. Spring MVC 핵심 구성 요소 (1)

① DispatcherSevlet 은 모든 연결을 담당하며, 웹 브라우저에서 요청이 들어오면 

② 그 요청을 처리하기 위해 HandlerMapping 객체에게 컨트롤러 검색을 요청한다.

    HandlerMapping은 클라이언트의 요청 경로를 이용해서 이를 처리할 컨트롤러 객체를 찾아서 DispatcherServlet 에 리턴한다.  

ex) root-context.xml 속

	<bean id="dataSource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
    
		<property name="driverClass" value="com.mysql.jdbc.Driver"></property>
 		<property name="url" value="jdbc:mysql://172.16.0.150:3306/btctrade?characterEncoding=UTF-8"></property> 
		<property name="username" value="btckorea"></property> 
		<property name="password" value="road0ds!32"></property> 
		
	</bean>

 

③  DispatcherServlet 은 @Controller 어노테이션을 이용해서 구현한 컨트롤러, 스프링 2.5까지 사용됐던 Controller 인터페이스를 구현한 컨트롤러, 특수 목적으로 사용되는 HttpRequestHandler 인터페이스를 구현한 클래스를 동일한 방식으로 실행하고 처리하기 위해 HandlerAdapter 객체에게 요청 처리를 위임한다.

④ HandlerAdapter 객체는 컨트롤러의 알맞은 메소드를 호출해서 요청을 처리하고,

⑤ 반환 받은 결과를 

⑥ ModelAndView 객체에 담아서 DispatcherServlet 에 리턴한다.

⑦ ModelAndView 객체를 반환 받은 DispatcherServlet 은 ViewResolver 객체를 이용해서 결과를 보여줄 뷰를 검색한다.

    ViewResolver 객체는 ModelAndView 객체에 담긴 뷰 이름을 이용해서 View 객체를 찾거나 생성해서 리턴한다.

    ViewResolver 는 매번 새로운 View 객체를 생성해서 DispatcherServlet에 리턴한다.

⑧ DispatcherServlet 은 ViewResolver 가 리턴한 View 객체에게 응답 결과 생성을 요청한다.

⑨ JSP를 사용하는 경우, View 객체는 JSP를 실행함으로서 브라우저에게 전송할 응답 결과를 생성한다.

    ModelAndView 의 Model 객체에 담겨 있는 데이터가 응답 결과에 필요하면 Model 에서 데이터를 꺼내 JSP 에서 사용할 수 있다.

 

 

클라이언트의 요청을 실제로 처리하는 것은 컨트롤러이고, 

DispatcherServlet 은 클라이언트의 요청을 전달 받는 창구 역할을 한다.

DispatcherServlet 에게 어떤 컨트롤러가 요청을 처리하는가는 중요하지 않으며, 

처리 결과를 ModelAndView 타입의 객체로 전달 받을 수 있기만 하면 된다.

이 때, 사용할 컨트롤러를 찾고, 처리 결과를 ModelAndView 객체로 변환해 주는 객체가 HandlerAdapter 이다.

 

핸들러 객체의 실제 타입마다 그에 알맞은 HandlerMapping 과 HandlerAdapter 가 존재하기 때문에,

사용할 핸들러의 종류에 따라 해당 HandlerMapping 과 HandlerAdapter 를 스프링 빈으로 등록해 주어야 하는데,

스프링 설정 기능(<mvc:annotaion-driven>)을 사용하면 직접 등록하지 않아도 스프링이 알아서 처리해 준다.

 

요청을 처리할 컨트롤러를 찾기 때문에 ControllerMapping 이라는 이름이 어울리는데,

스프링 MVC 는 웹 요청을 처리할 수 있는 범용적인 프레임워크를 제공하고 있기 때문에,

클라이언트의 요청을 처리하는 객체가 컨트롤러가 아닐 수도 있다(HttpRequestHandler 등).

그래서 스프링 MVC 는 웹 요청을 실제로 처리하는 객체를 Handler 라고 표현하고 있다.

따라서 컨트롤러는 DispatcherServlet 입장에서 보면 한 종류의 핸들러 객체이다.

 

5. Spring MVC 핵심 구성 요소 (2) 설명2

1. 클라이언트가 해당 어플리케이션에 접근하면 접근한 URL 요청을 DispatcherServlet 이 가로챕니다. 이렇게 요청을 가로챌 수 있는 이유는 web.xml 에 등록된 DispatcherServlet 의 <url-pattern>이 ‘/’ 와 같이 해당 어플을 통과하는 모든 URL로 등록했기 때문입니다. 특정 URL 만 적용하고 싶다면 <url-pattern> 의 내용을 바꿔주어 범위를 변경시켜주면 됩니다.

2. 가로챈 정보를 HandlerMapping 에게 보내 해당 요청을 처리할 수 있는 Controller 를 찾아냅니다. (스프링은 기본적으로 5가지의 핸들러 매핑을 제공합니다.) 이 부분은 스프링의 디폴트 전략에 의해 BeanNameUrlHandlerMapping과 DefaultAnnotationHandlerMapping 이 기본으로 Spring MVC에 탑재되있기 때문에 특별한 경우가 아니면 따로 설정할 필요가 없습니다.

3. 핸들러 매핑이 해당 요청을 처리할 컨트롤러를 찾아냈다면 요청을 컨트롤러에 보내줍니다. 컨트롤러는 사용자가 직접 구현해주는 부분입니다. @MVC는 매우 다양한 코딩방식과 직관적이고 편리한 컨트롤러 작성방법을 제공하므로 이 부분에 대해서는 차후 심층적인 분석으로 자신에게 알맞는 전략을 선정해야합니다.

4. 해당 요청을 처리한 후에 컨트롤러는 요청을 응답받을 View 의 이름을 리턴하게 됩니다. ( 물론 다른 핸들러 매핑 전략을 이용한다면 응답 과정이 다를 수도 있습니다. ) 그 때 이 이름을 ViewResolver 가 먼저 받아 해당하는 View가 존재하는지 검색합니다.

5. 컨트롤러에서 보내온 View 이름을 토대로 처리 View 를 검샙합니다.

6. 해당 View가 있다면 처리결과를 View에 보낸 후 7. 이 결과를 다시 DispatcherServlet 에 보낸 후 8. DispatcherServlet 은 최종 결과를 클라이언트에 전송합니다.

 

자원의 분리

• ’/’ 요청에 대한 모든 처리를 DispatcherServlet 이 담당한다면, 비어플리케이션 자원 (js, css …)에 대해서도 컨트롤러를 찾아 해매는 에러가 발생할 수 있다.
• 그에 따라 Spring 은 자원을 분리할 수 있는 기능을 추가 시켜놓았다.
• 이와 같은 처리는 preference의 Deplyment Assembly에 가면 확인 가능하다.

 

servlet-context.xml 파일 안

<resources mapping="/resources/-*" location="/resources/" />

• <mvc:resources> 는 디스패처 서블릿이 해당 요청을 컨트롤러에서 찾지 못했을 때 2차적으로 위의 설정된 경로를 검색하여 해당 자원을 찾아내게 하는 것입니다.
• 어플리케이션 자원과 비어플리케이션 자원( js, css …)을 분리하여 resources 폴더에서 따로 관리 가능하도록 한 것 입니다.