@AutoWired : 의존 관계를 자동으로 설정할 때 사용되는 기능이며, 생성자, 필드, 메서드의 3곳에 적용 가능함. 의존관계는 Bean간의 의존관계로 생각하면 됨.
- AutoworedAnnotationBeanPostProcessor
@Resource : java 6 및 jee5 버전에 추가된 어노테이션 기능으로 어플리케이션에서 필요로 하는 자원을 자동으로 연결할 때 사용함. AutoWired와 유사함. 하지만 어노테이션 뒤에 name 속성이 들어감.
- CommonAnnotationBeanPostProcessor
ex) @Resource(name="hello")
리소스 어노테이션을 사용하기 위해서는 CommonAnnotationBeanPostProcesser을 등록하거나 <context:annotation-config>를 사용하면 됨.
※ AutoWired와 Resource의 차이점
- AutoWired는 Spring Framework에서 지원하는 Dependency 정의 용도의 annotation으로, 스프링에 종속적이긴하지만 정밀한 Dependency Injection이 필요한 경우에 유요함.
- Resource는 JSR-250 표준 annotation으로 스프링2.5 이상부터 지원 가능한 annotation임. annotation으로 인해 특정 프레임워크에 종속적인 어플리케이션을 구성하지 않기 위해서 @Resource를 사용함. 사용하기 위해서는 클래스패스 내에 jsr250-api.jar 파일이 추가되어야 함.
비록, Spring이 스트러츠를 비롯하여 다양한 웹 프레임워크와 비교적 잘 연동되는 편이긴 하지만, 서로 다른 두 프레임워크를 연동하기 위해서는 설정의 중복 등 개발 과정에서 불편함이 존재한다. 서로 잘 맞지 않는 단추를 억지로 끼워 맞추는 것 같다.
Spring 자체적으로 제공하는 MVC 프레임워크를 사용하면, Spring이 제공하는 AOP, 트랜잭션 처리, DI 등의 기능을 그대로 사용하면서 MVC 패턴에 기반하여 웹 어플리케이션을 개발할 수 있다. 또한, 스트러츠와 Spring을 연동하기 위해 설정의 중복과 같은 개발 과정상의 불편을 해소할 수도 있다.
본 글에서는 Spring MVC의 구성에 대해서 살펴보고, 실제로 Spring MVC를 사용하여 웹 어플리케이션을 개발하는 기본적인 방법을 살펴보도록 하겠다. 그외 Spring MVC를 이용한 웹 어플리케이션에 대해 좀더 자세한 내용이 알고 싶다면http://www.springframework.org/documentation사이트를 참고하기 바란다.
Spring MVC의 구성 및 실행 흐름
다른 MVC 기반의 프레임워크와 마찬가지로 Spring MVC도 컨트롤러를 사용하여 클라이언트의 요청을 처리하게 된다. 이 컨트롤러의 역할을 하는 것이 DispatcherServlet인데, DispatcherServlet을 비롯하여 Spring MVC의 주요 구성 요소는 표 1과 같다.
구성 요소
설명
DispatcherServlet
클라이언트의 요청을 전달받는다. Controller에게 클라이언트의 요청을 전달하고, Controller가 리턴한 결과값을 View에 전달하여 알맞은 응답을 생성하도록 한다.
HandlerMapping
클라이언트의 요청 URL을 어떤 Controller가 처리할지를 결정한다.
Controller
클라이언트의 요청을 처리한 뒤, 그 결과를 DispatcherServlet에 알려준다. 스트러츠의 Action과 동일한 역할을 수행한다.
ViewResolver
Commander의 처리 결과를 보여줄 View를 결정한다.
View
Commander의 처리 결과를 보여줄 응답을 생성한다.
이들 주요 구성 요소간의 메시지 흐름은 그림 1과 같다.
각 흐름을 좀더 자세하게 설명하면 다음과 같다.
클라이언트의 요청이 DispatcherServlet에 전달된다.
DispatcherServlet은 HandlerMapping을 사용하여 클라이언트의 요청이 전달될 Controller 객체를 구한다.
DispatcherServlet은 Controller 객체의 handleRequest() 메소드를 호출하여 클라이언트의 요청을 처리한다.
Controller.handleRequest() 메소드는 처리 결과 정보를 담은 ModelAndView 객체를 리턴한다.
DispatcherServlet은 ViewResolver로부터 처리 결과를 보여줄 View를 구한다
View는 클라이언트에 전송할 응답을 생성한다.
여기서 개발자가 직접 개발해주어야 하는 부분은 클라이언트의 요청을 처리할 Commander 클래스와 클라이언트에 응답 결과 화면을 전송할 JSP나 Velocity 템플릿 등의 View 코드이다. 나머지, DispatcherServlet이나 HandlerMapping, ViewResolver 등은 Spring이 제공하는 기본 구현체를 사용하면 된다.
Spring MVC를 이용한 웹 어플리케이션 개발
Spring MVC를 이용하여 웹 어플리케이션을 개발하는 과정은 다음과 같다.
클라이언트의 요청을 받을 DispatcherServlet을 web.xml 파일에 설정한다.
요청 URL과 Controller의 매핑 방식을 설정한다.
Controller의 처리 결과를 어떤 View로 보여줄 지의 여부를 결정하는 ViewResolver를 설정한다.
Controller를 작성한다.
뷰 영역의 코드를 작성한다.
DispatcherServlet 설정 및 Spring 콘텍스트 설정
Spring MVC를 사용하기 위해서는 가장 먼저 web.xml 파일에 DispatcherServlet 설정을 추가해주어야 한다. DispatcherServlet은 서블릿 클래스로서 다음과 같이 서블릿 설정 및 서블릿 매핑 설정을 web.xml 파일에 추가해주면 된다.
위 설정은 모든 *.do로 들어오는 요청을 DispatcherServlet이 처리하도록 하고 있다.
DispatcherServlet은 설정 파일에서 지정한 서블릿 이름을 사용하여 Spring 설정 파일을 로딩한다. 예를 들어, 위 코드의 경우 DispatcherServlet의 이름이 "example"인데, 이 경우 사용되는 Spring 설정 파일은 'WEB-INF/example-servlet.xml' 이다.
만약 기본적으로 사용되는 Spring 콘텍스트 설정 파일이 아닌 다른 이름의 파일을 사용하고 싶다면 다음과 같이 contextConfigLocation 초기화 파라미터에 사용할 설정 파일의 목록을 지정해주면 된다.
이때 각 설정 파일은 콤마를 사용하여 구분한다. 만약 각 설정 파일에서 동일한 이름의 빈을 지정했다면 더 뒤에 위치한 설정 파일에 명시된 빈이 우선순위를 갖는다.
HandlerMapping 설정
클라이언트의 요청을 Spring의 DispatcherServlet이 처리하도록 설정했다면, 다음으로 해야 할 작업은 어떤 HandlerMapping을 사용할지의 여부를 지정하는 것이다. HandlerMapping은 클라이언트의 요청을 어떤 Commender가 수행할 지의 여부를 결정해주는데, 표 2와 같이 두 개의 구현체가 주로 사용된다.
구현체
설명
BeanNameUrlHandlerMapping
요청 URI와 동일한 이름을 가진 Controller 빈을 매핑한다.
SimpleUrlHandlerMapping
Ant 스타일의 경로 매핑 방식을 사용하여 URI와 Controller 빈을 매핑한다.
BeanNameUrlHandlerMapping
BeanNameUrlHandlerMapping은 요청 URI와 동일한 이름을 갖는 Controller 빈으로 하여금 클라이언트의 요청을 처리하도록 한다. 예를 들어, http://some.com/hello.do 와 같은 요청 URL에 대해 "/hello.do" 라는 이름을 가진 Controller 빈이 해당 요청을 처리하도록 한다. 아래 코드는 BeanNameUrlHandlerMapping를 사용하는 경우의 Spring 설정 파일의 예를 보여주고 있다.
만약 요청 URL이 http://some.com/login.do 였다면, 이름이 "/login.do"인 LoginController가 해당 요청을 처리하게 된다. 비슷한 이유로, http://some.com/hello.do 요청은 HelloController가 처리하게 된다.
HandlerMapping 빈을 따로 생성하지 않은 경우 DispatcherServlet은 기본적으로 HandlerMapping의 구현체로 BeanNameUrlHandlerMapping을 사용한다. 따라서, 위 코드에서 HandlerMapping과 관련된 설정은 생략할 수 있다.
SimpleUrlHandlerMapping
SimpleUrlHandlerMapping은 Ant 스타일의 매핑 방식을 사용하여 Controller를 매칭한다. 아래 코드는 SimpelUrlHandlerMapping을 사용하여 클라이언트의 요청 URL과 매핑될 Controller를 지정하는 예를 보여주고 있다.
SimpleUrlHandlerMapping은 mappings 프로퍼티를 통해서 매핑 설정 목록을 입력받는다. 이때 설정의 이름은 Ant 스타일의 URL 경로를 의미하며, 값은 매핑될 Controller 빈의 이름을 의미한다. 예를 들어, 위 예제의 경우 http://some.com/content/1.html 이나 http://some.com/content/mvc.html 요청이 들어오면 contentController가 처리하도록 매핑하였다.
SimpleUrlHandlerMapping에서 사용되는 규칙은 다음과 같다.
? - 한 글자에 매칭된다.
* - 0 개 이상의 글자에 매칭된다.
** - 0개 이상의 디렉토리에 매칭된다.
아래는 org.springframework.util.AntPathMatcher API 문서에 예시로 나온 몇 가지 매핑 설정의 예이다.
com/t?st.jsp - com/test.jsp, com/tast.jsp 또는 com/txst.jsp 등에 매칭된다.
com/*.jsp - com 디렉토리에 있는 모든 .jsp에 매칭된다.
com/**/test.jsp - com 경로 아래에 위치한 모든 test.jsp와 매칭된다.
org/springframework/**/*.jsp - org/springframework 경로 아래에 위치한 모든 jsp와 매칭된다.
두 HandlerMapping 구현체의 공통 프로퍼티
앞서 살펴본 두 HandlerMapping 구현 클래스는 AbstractUrlHandlerMapping 클래스를 상속받고 있으며, AbstractUrlHandlerMapping 클래스는 AbstractHandlerMapping 클래스를 상속받고 있다. 이 두 클래스는 공통으로 사용되는 몇 가지 프로퍼티를 제공하고 있는데, 먼저 AbstractHandlerMapping 클래스는 다음과 같은 프로퍼티를 제공하고 있다.
프로퍼티
설명
interceptors
사용할 인터셉터의 목록
defaultHandler
매칭되는 핸들러를 찾지 못할 때 사용할 기본 핸들러
order
하나의 서블릿 콘텍스트에서 다수의 HandlerMapping을 사용할 수 있는데, 이 경우 HandlerMapping 간의 우선순위를 지정한다.
AbstractUrlHandlerMapping 클래스가 제공하는 프로퍼티 목록은 표 4와 같다.
프로퍼티
설명
alwaysUseFullPath
웹 어플리케이션 콘텍스트의 경로를 포함할 지의 여부를 결정한다. 예를 들어, 콘텍스트 경로가 /main 일때, http://some.com/main/a.html 에 대해, 이 값이 true면 /main/a.html 이 사용된다. 이 값이 false이면 /a.html이 사용된다. 기본값은 false이다.
urlDecode
HandlerMapping에 요청 URL을 전달하기 전에 특정 인코딩을 사용해서 디코딩할지의 여부를 결정한다. 이 값을 true로 지정하면 요청에 명시된 인코딩이나 ISO-8859-1을 사용하여 디코딩한다. 기본값은 false이다.
lazyInitHandlers
싱글톤 타입의 핸들러에 대해 lazy initialization을 적용할지의 여부를 지정한다. 기본 값은 false이다.
ViewResolver 설정
HandlerMapping을 설정했다면, 이제 ViewResolver를 설정할 차례이다. ViewResolver는 Controller의 실행 결과를 어떤 뷰를 보여줄지의 여부를 결정하는 기능을 제공한다. 주로 사용되는 ViewResolver에는 다음의 두 가지가 존재한다.
InternalResourceViewResolver - JSP를 사용하여 뷰를 생성한다.
VelocityViewResolver - Velocity 템플릿 엔진을 사용하여 뷰를 생성한다.
InternalResourceViewResolver
InternalResourceViewResolver는 JSP를 사용하여 Commander의 결과 뷰를 생성할 때 사용된다. 아래 코드는 InternalResourceViewResolver의 설정 예를 보여주고 있다.
InternalResourceViewResolver는 다음과 같이 두 개의 프로퍼티를 입력받는다.
prefix - Controller가 리턴한 뷰 이름 앞에 붙을 접두어
suffix - Controller가 리턴한 뷰 이름 뒤에 붙을 확장자
예를 들어, HelloController가 처리 결과를 보여줄 뷰의 이름으로 "hello"를 리턴했다고 하자. 이 경우 InternalResourceViewResolver에 의해 사용되는 뷰는 "/view/hello.jsp"가 된다. 따라서, /view/hello.jsp가 생성한 응답 결과 화면이 클라이언트에 전달된다.
VelocityViewResolver
VelocityViewResolver는 Velocity 템플릿을 사용하여 뷰를 생성할 때 사용된다. 아래 코드는 VelocityViewResolver의 설정 예를 보여주고 있다.
VelocityViewResolver를 사용하기 위해서는 먼저 Velocity의 설정 정보를 관리해주는 VelocityConfigurer를 생성해주어야 한다. VelocityConfigurer에서 사용가능한 주요 프로퍼티는 다음과 같다.
resourceLoaderPath - Velocity 템플릿이 위치하는 경로 (웹 콘텍스트 루트 기준)
velocityProperties - Velocity 설정 프로퍼티
예를 들어, 위 코드의 경우는 웹 어플리케이션 루트에 위치한 /view_vm/ 디렉토리에 Velocity 템플릿 파일이 위치한다는 것을 의미한다.
VelocityViewResolver를 설정할 때에는 다음의 프로퍼티를 알맞게 지정해준다.
contentType - 응답의 컨텐트 타입을 지정한다.
prefix - InternalResourceViewResolver와 동일
suffix - InternalResourceViewResolver와 동일
위 설정의 경우, Controller가 선택한 뷰가 "hello"라고 한다면 /view_vm/hello.vm 파일이 템플릿으로 선택된다. 또한 생성되는 뷰의 컨텐트 타입은 "text/html" 이고 캐릭터셋은 UTF-8이 된다.
Controller 구현
지금까지는 환경 설정과 관련된 부분에 대해서 설명했는데, 이제 본격적으로 클라이언트의 요청을 처리하는 데 사용되는 Controller의 구현에 대해서 살펴보도록 하자. Controller를 구현하는 가장 간단한 방법은 Controller 인터페이스를 implements 하는 것이다. 하지만, Controller 인터페이스를 직접적 implements 하기 보다는, Controller 인터페이스를 implements 하고 몇 가지 추가적인 기능을 구현하고 있는 클래스들을 상속받아 Controller를 구현하는 것이 일반적이다.
Controller 인터페이스
org.springframework.web.servlet.mvc.Controller 인터페이스는 다음과 같이 정의되어 있다.
public class SimpleController implements Controller {
public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { // request를 사용하여 클라이언트 요청 분석 후 // 클라이언트 요청에 따른 알맞은 처리 ModelAndView mav = new ModelAndView("hello"); mav.addObject("greeting", "안녕하세요"); return mav; }
}
handleRequest() 메소드는 파라미터로 전달받은 request 객체와 response 객체를 사용하여 클라이언트가 요청한 기능을 알맞게 구현하면 된다.
handleRequest() 메소드는 ModelAndView 객체를 리턴한다. ModelAndView 객체는 클라이언트의 요청을 처리한 결과를 보여줄 뷰 페이지와 관련해서 다음과 같은 정보를 제공한다.
결과를 보여줄 뷰 이름 지정 : 위 코드의 경우 "hello"를 뷰로 선택
뷰에서 사용할 모델 데이터 : 위 코드의 경우 addObject() 메소드로 추가한 객체, 뷰에서는 "greeting" 이라는 이름을 사용하여 데이터에 접근할 수 있다.
위 viewResolver는 "/view/" + 뷰이름 + ".jsp"를 뷰로 사용하게 된다. SimpleController는 뷰 이름으로 "hello"를 리턴하므로, "/view/hello.jsp"가 뷰로 사용된다. 또한, 이 뷰에서는 다음과 같이 ModelAndView에 저장된 객체를 사용할 수 있게 된다.
Controller를 구현할 때에는 Controller 인터페이스를 직접 구현하기보다는, AbstractController 추상 클래스를 상속 받아 구현하는 경우가 더 많다. AbstractController 클래스는 Controller 인터페이스를 implements 하여 추가적인 기능을 제공하고 있다.
AbstractController 클래스는 표 5와 같은 프로퍼티를 제공하고 있으며, 이 프로퍼티를 사용하여 HTTP Session, 캐시 등의 설정을 제어할 수 있다.
프로퍼티
설명
supportedMethods
Controller가 처리할 수 있는 메소드를 지정한다. GET과 POST 등 처리할 수 있는 메소드를 지정할 수 있다. 만약 지원되지 않는 메소드를 사용하여 요청이 들어오면 ServletException 예외를 발생시킨다.
requiresSession
Controller가 HTTP Session을 필요로 하는 지의 여부를 지정한다. 이 값이 true인 경우, 클라이언트와 관련된 세션이 존재하지 않으면 ServletException 예외를 발생시킨다.
synchronizeSession
HTTP Session을 사용하여 Controller에 대한 처리를 동기화 할지의 여부를 지정한다.
cacheSeconds
HTTP 응답에 캐시와 관련된 디렉티브를 생성할지의 여부를 지정한다. 기본 값은 -1이며, 이 경우 캐시 디렉티브가 응답 결과에 포함되지 않는다.
useExpiresHeader
HTTP 1.0에 호환되는 "Expires" 헤더의 사용 여부를 지정한다. 기본값은 true 이다.
useCacheHeader
HTTP 1.1에 호환되는 "Cache-Control' 헤더의 사용 여부를 지정한다. 기본값은 true 이다.
AbstractController 클래스를 상속받아 Controller를 구현하는 클래스는 아래 코드와 같이 handleRequestInternal() 메소드를 구현해주면 된다.
AbstractController 클래스의 handleRequest() 메소드는 내부적으로 필요한 작업을 수행한 뒤, handleRequestInternal() 메소드를 호출한다. 따라서, AbstractController 클래스를 상속받는 경우에는 handleRequest() 메소드가 아닌 handlerRequestInternal() 메소드를 구현해주어야 한다.
AbstractCommandController를 이용한 파라미터 값 전달
요청 파라미터의 값을 특정한 객체에 저장하고 싶다면 AbstractCommandController 클래스를 사용하면 된다. AbstractCommandController 클래스를 상속받은 클래스는 다음과 같이 handle() 메소드를 알맞게 구현해주면 된다.
handle() 메소드에 전달되는 command 파라미터는 commandClass 프로퍼티에 지정한 타입의 객체가 된다. 이때 파라미터와 생성할 command 객체의 프로퍼티 사이의 매핑은 자바빈 스타일을 따른다. 예를 들어, 파라미터 이름이 id 인 경우 setId() 메소드를 통해 파라미터 값이 전달되며, 파라미터 이름이 address 인 경우 setAddress() 메소드를 통해 파라미터 값이 전달된다.
SimpleFormController를 이용한 폼 전송 처리
SimpleFormController는 AbstractCommandController와 마찬가지로 파라미터의 값을 객체에 저장할 때 사용된다. 차이점이 있다면, SimpleFormController는 폼 전송 개념이 적용되어 있다는 것이다. SimpleFormController는 POST 방식으로 요청이 들어올 경우 doSubmitAction() 메소드를 통해 요청을 처리하는 반면에, GET 방식으로 요청이 들어오면 "formView" 프로퍼티로 지정한 뷰를 출력한다.
SimpleFormController는 클라이언트가 POST로 전송한 데이터는 commandClass 프로퍼티로 지정한 타입의 객체에 저장되어 doSubmitAction() 메소드에 전달된다. 아래 코드는 SimpleFormController의 구현 예를 보여주고 있다.
위 코드에서 super.doSubmit() 메소드를 호출하면 doSubmitAction() 메소드가 호출된다. 따라서, doSubmitAction() 메소드가 성공적으로 수행되면 ModelAndView.addObject() 메소드를 사용하여 뷰에 데이터를 전달할 수 있게 된다.
뷰의 구현
뷰에서는 ModelAndView 객체에 저장한 객체를 사용할 수 있다. 예를 들어, Controller에서 다음과 같이 ModelAndView에 데이터를 저장했다고 해 보자.