토비의스프링3.1 2권 3장. 스프링 웹 기술과 스프링 MVC
3장. 스프링 웹 기술과 스프링 MVC
3.1 스프링의 웹 프레젠테이션 계층 기술
스프링 웹 서블릿 컨텍스트의 분리
- 루트 앱 컨텍스트
- 서블릿 앱 컨텍스트
- 스프링은 의도적으로 서블릿 웹 앱의 컨텍스트를 두 가지로 분리해놓았다.
- 웹 기술에서 완전히 독립적인 비즈니스 서비스 계층과 데이터 액세스 계층을 담은 루트 앱 컨텍스트와
- 스프링 웹 기술을 기반으로 동작하는 웹 관련 빈을 담은 서블릿 앱 컨텍스트다.
- 이렇게 스프링 컨텍스트를 두 가지로 분리해둔 이유는 스프링 웹 서블릿 컨텍스트를 통째로 다른 기술로 대체할 수 있도록 하기 위해서다.
3.1.1 스프링에서 사용되는 웹 프레임워크 종류
스프링 서블릿/스프링 MVC
- 스프링이 직접 제공하는 서블릿 기반의 MVC프레임워크다.
- 스프링 서블릿 또는 스프링 MVC라고 부른다.
- 프론트 컨트롤러 역할을 하는 DispatcherServlet을 핵심엔진으로 사용한다.
- 스프링 서블릿은 다양한 종류의 컨트롤러를 동시에 사용할 수 있게 설계되어 있다.
- 스프링답게 MVC 프레임워크의 많은 기능을 자유롭게 확장할 수 있다.
- 스프링 서블릿이 제공해주는 공통 서비스와 전략들을 기반으로 해서 새로운 종류의 MVC프레임워크를 만드는 일도 어렵지 않다.
- 애노테이션 설정과 유연한 핸들러 메소드를 지원하는 스프링 @MVC가 가장 대표적으로 사용되는 스프링 서블릿 기반의 기술이다.
- 스프링 서블릿의 모든 컴포넌트는 스프링의 서블릿 ac의 빈으로 등록되어 동작한다.
- 따라서 간단히 루트 컨텍스트에 존재하는 서비스 계층의 빈을 사용할 수 있다.
- 스프링 서블릿의 구성요소와 전략,특징을 살펴보자.
* SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다.
스프링 포트폴리오 웹 프레임워크
- Spring Web Service
- 스프링 MVC와 유사한 방식으로 SOAP 기반의 웹 서비스 개발을 가능하게 해주는 프레임워크다.
- 강력한 오브젝트 매핑 기능과 XML 마샬링 기능을 제공.
- 스프링 보안을 비롯한 각종 스프링의 기능을 활용가능.
스프링 기반으로 두지 않는 웹 프레임워크
- JPS/Servlet
- 기존에 만들어뒀떤 모델 1 방식의 JSP나 서블릿을 스프링 앱의 웹 프레젠테이션 계층으로 사용할 수 있다.
- JSP나 서블릿에서 newXXXHelper()와 같은 방식으로 헬퍼 오브젝트를 만들어서 DB나 비즈니스 로직을 처리하고 있었다면, 이를 스프링으로 만들어둔 서비스계층이나 데이터액세스 계층의 빈을 가져와 사용하도록 만들 수 있다.
3.1.2 스프링 MVC와 DispatcherServlet 전략
프레임워크 기술의 방향
- 스프링과 같이 유연성과 확장성에 중점을 둔 범용적 프레임워크
- 기술에 대한 자기 주장이 강하고 기술 선호도가 분명해서 제한적인 기술만을 사용하도록 강제하는 프레임워크
프레임워크 기술은 2가지 방향으로 발전하고 있다.
하나는 스프링과 같이 유연성과 확장성에 중점을 두고 어떤 종류의 시스템 개발이나 환경, 요구조건에 잘 들어맞도록 재구성할 수 있는 범용적 프레임워크.
- 이런 프레임워크는 각 계층과 기술 사이의 독립성이 중요.
- 따라서 계층과 기술이 서로의 내부를 잘 알고 강하게 결합되는 것을 극도로 꺼린다.
- 모든 계층에서 공유 가능한 도메인 오브젝트 정도를 제외하면 각 계층은 정해진 인터페이스 외에는 서로 알지못한다.
- 각 계층을 독립적으로 개발하고 테스트할 수 있으며 한 계층의 기술이나 구현은 다른 계층의 코드에 영향을 주지 않은 채로 자유롭게 변경하거나 교체할 수 있다.
- 같은 계층에서도 환경에 종속적인 로우레벨의 기술과 상위 레벨의 앱 코드는 서비스 추상화와 같은 방식으로 최대한 느슨하게 연결해서 의존성이 발생하지 않도록 만든다.
- 유연한 아키텍쳐를 가지고 장기적으로 많은 인원이 큰 규모의 시스템을 개발할 때 적합한 프레임워크다.
스프링 웹 프레임워크의 이상적인 사용법
- 스프링을 사용하는 개발자는 스프링이 제공해준 MVC 프레임워크 위에 필요한 전략을 추가해서 사용할 수 있어야 한다.
- 스프링 MVC프레임워크를 이미 완성된 고정적인 프레임워크로 보지말고, 진행하려는 프로젝트의 특성에 맞게 빠르고 편리한 개발이 가능하도록 자신만의 웹 프레임워크를 만드는 데 쓸 수 있는 도구라고 생각할 필요가 있다.
- 이것이 스프링이 제공하는 가치를 누리며 스프링을 잘 사용할 수 있는 비결이다.
스프링 웹 프레임워크의 올바른 사용법 : 확장
- 일단 먼저 스프링의 웹 기술이 제공하는 유연하고 확장성 뛰어난 기반구조를 확실히 이해하고 난 후에
- 이를 스프링이 어떻게 확장해서 웹 프레임워크를 만들었는지 살펴보고
- 이를 다시 확장해서 프로젝트에 맞는 편리하고 빠른 개발이 가능한 프레임워크를 만드는 게 좋을 것이다.
DispatcherServlet
- 스프링 웹 기술의 핵심이자 기반이 되는 것은 DispatcherServlet이다. 이 서블릿은 스프링의 웹 기술을 구성하는 다양한 전략을 DI로 구성해서 확장하도록 만들어진 스프링/MVC의 엔진과 같은 역할을 한다.
DispatcherServlet과 MVC 아키텍쳐
- 스프링의 웹 기술은 MVC 아키텍처를 근간으로 하고 있다.
- MVC는 프레젠테이션 계층의 구성요소를 정보로 담은 모델(M), 화면 출력 로직을 담은 뷰(V), 그리고 제어 로직을 담은 컨트롤러(C)로 분리하고
- 이 세 가지 요소가 서로 협력해서 하나의 웹 요청을 처리하고 응답을 만들어내는 구조다.
- MVC아키텍쳐는 보통 프론트 컨트롤러 패턴과 함께 사용된다.
- 중앙집중형 컨트롤러를 프레젠테이션 계층의 제일 앞에 둬서 서버로 들어오는 모든 요청을 먼저 받아서 처리하게 만든다.
- 예외 발생 시 이를 처리하는 것도 프론트 컨트롤러의 역할.
간단 요약.
1. HTTP요청
2. 컨트롤러에게 어댑터를 이용해서 HTTPservletrequst타입의 오브젝트를 전달. response도 함께 전달.
3. 사용자의 요청을 해석하고, 비즈니스 로직을 수행하도록 서비스계층 오브젝트에 작업 위임, 그리고 결과 받아서 모델 생성, 마지막으로 어떤 뷰를 사용할지 결정. 그리고 모델과 뷰 리턴.
4. 뷰의 논리적인 이름을 리턴해주면 뷰 리졸버가 이를 이용해 뷰 오브젝트생성하고 모델을 참조해 최종 결과물을 생성. 최종 결과물은 HTTpServletResponse 오브젝트안에 담긴다.
5. HTTP 응답 돌려주기. 최종 결과를 서블릿 컨테이너에게 돌려주고 response에 담긴 정보를 HTTP응답으로 만들어 사용자 브라우저나 클라이언트에 전송하고 작업을 종료.
★★ DispatcherServlet의 DI 가능한 전략 (7가지)
- DispatcherServlet은 DI로 확장 가능한 여러 전략들이 있다.
- 스프링 MVC는 자주 사용되는 전략을 디폴트로 설정해주고 있다.
- 따라서 필요한 전략만 확장해서 사용하고 나머지는 디폴트 전략을 사용해도 된다.
다음 전략들은 DispatcherServlet의 동작 방식을 확장하는 확장 포인트라고 할 수 있다.
- DispatcherServlet은 서블릿 컨테이너가 생성하고 관리하는 오브젝트이지, 스프링 컨텍스트에서 관리하는 빈 오브젝트가 아니다.
- 하지만 DispatcherServlet은 내부에 서블릿 웹 애플리케이션 컨텍스트를 가지고 있고 내부 컨텍스트로부터 전략이 담긴 빈 오브젝트를 찾아 사용한다.
- DispatcherServlet에 적용할 전략을 선택하고, 필요에 따라 확장하거나 다른 방식으로 사용하는 것이 스프링 MVC를 바로 사용하는 첫 걸음이다.
★★ DispatcherServlet의 DI 가능한 전략 (7가지)
1. HandlerMapping
- URL과 요청 정보를 기준으로 어떤 컨트롤러 오브젝트를 사용할 것인지를 결정하는 로직을 담당한다.
- 디폴트: BeanNameUrlHandlerMapping과 DefaultAnnotationHandlerMapping
2. HandlerAdapter
- 핸들러 매핑으로 선택한 컨트롤러를 DispatcherServlet이 호출할 때 사용하는 어댑터다.
- 디폴트: HttpRequestHandlerAdapter,SimpleControllerHandlerAdapter,AnnotationMethodHandlerAdapter
3. HandlerExceptionResolver
- 예외가 발생했을 때, 이를 처리하는 로직을 갖고 있다.
- 디폴트: AnnotationMethodHandlerExceptionResolver, ResponseStatusExceptionResolver, DefaultHandlerExceptionResolver
4. ViewResolver
- 컨트롤러가 리턴한 뷰 이름을 참고해서 적절한 뷰 오브젝트를 찾아주는 로직을 가진 전략 오브젝트다.
- 디폴트: InternalResourceViewResolver
5. LocaleResolver
- 지역(locale)정보를 결정해주는 전략이다.
- 디폴트: AcceptHeaderLocaleResolver
6. ThemeResolver
- 테마를 가지고 이를 변경해서 사이트를 구성할 경우 쓸 수 있는 테마 정보를 결정해주는 전략이다.
7. RequestToViewNameTranslator
- 컨트롤러에서 뷰 이름이나 뷰 오브젝트를 제공해주지 않았을 경우 URL과 같은 요청정보를 참고해서 자동으로 뷰 이름을 생성해주는 전략이다.
- 디폴트: DefaultRequestToViewNameTrannslator
결론
- DispatcherServlet을 프론트 컨트롤러로 사용하는 스프링 MVC의 가장 큰 특징은 매우 유연한 컨트롤러 호출 방식을 사용한다는 것이다.
- 컨트롤러 종류에 제약을 받지 않고, 적절한 어댑터만 제공해준다면 다양한 종류의 컨트롤러를 사용할 수 있다.
3.2 스프링 웹 애플리케이션 환경 구성
3.3 컨트롤러
컨트롤러는 MVC의 세 가지 컴포넌트 중에서 가장 많은 책임을 지고 있다.
- 서블링시 넘겨주는 HTTP요청은 HttpServletRequest 오브젝트에 담겨 있다.
- 컨트롤러가 이를 이용해 사용자의 요청을 파악하려면 클라이언트 호스트, 포트, URI, 쿼리 스트링, 폼파라미터, 쿠키, 헤더, 세션을 비롯해서 서블릿 컨테이너가 요청 애트리뷰트로 전달해주는 것까지 매우 다양한 정보를 참고해야 한다.
- HttpServletRequest에서 필요한 사용자 요청정보를 추출했다고 해서 끝이 아니다. 사용자가 바르게 요청을 보냈는지도 검증해야 한다.
- 사용자 요청을 모두 분석한 후에 서비스 계층의 비즈니스 로직을 담당하는 메소드를 불러서 요청에 따른 작업을 수행할 수 있다.
- 이 과정에서 컨트롤러의 역할은 서비스 계층의 메소드를 선정하는 것과 메소드가 필요로 하는 파라미터 타입에 맞게 요청 정보를 변환해 주는 것이다.
- 대부분 서비스계층 메소드는 리턴값이나 예외를 이용해 결과를 돌려준다. 때로는 간단한 숫자나 문자열일 수도 있지만, 때로는 복잡한 오브젝트나 컬렉션,배열일 수도 있다.
- 컨트롤러는 서비스계층의 메소드가 돌려준 결과를 보고 어떤 뷰를 보여줘야 하는지 결정해야 한다. 때로는 페이지가 바뀌도록 리다이렉트해줘야 한다.
- 뷰 선택이 끝나면 다음은 뷰에 출력할 내용을 모델에 적절한 이름으로 넣어줘야 한다.
- 서비스 계층 메서드가 돌려주는 값이 그대로 들어가기도 하지만, 때로는 컨트롤러가 모델 정보를 생성할 수도 있다.
- URL 파라미터를 통해서 페이지가 바뀌어도 검색조건이나 페이지 번호 등을 유지해야 한다면, HTML에 들어갈 URL이나 폼의 히든 필드에 저장할 파라미터 정보 등을 가공해서 모델에 넣어주기도 한다.
- 상테를 세션에 저장하는 경우도 있다.
- 이어지는 요청에서도 계속 유지돼야 하는 정보가 있고, 이를 DB나 URL파라미터, 쿠키에 저장하기 어려운 경우엔 HTTP세션에 정보를 저장해두는 것도 컨트롤러의 책임이다.
- 때로는 더 이상 필요 없어진 세션의 오브젝트를 제거해주는 작업도 필요하다. 이 작업을 빼먹으면 HTTP 세션에 필요없는 오브젝트가 세션이 끝날 떄까지 누적되는 일종의 메모리 누수 버그가 발생할 수도 있다.
- 이런 모든 작업을 컨트롤러 메소드 하나에 모두 담아두는 건 비효율적이며 객체지향적이라고 보기도 힘들다.
- 스프링 MVC가 컨트롤러 모델을 미리 제한하지 않고 어댑터 패턴을 사용해서라도 컨트롤러의 종류를 필요에 따라 확장할 수 있도록 만든이유가 이 때문이다.
- 우리는 스프링 MVC가 제공하는 컨트롤러의 종류와 그에 따른 핸들러 어댑터를 알아보고, 필요에 따라 컨트롤러를 설계하고 만드는 방법도 살펴보자.
- 그리고 URL과 핸들러를 연결해주는 핸들러 매핑에 대해서도 도 알아보자.
3.3.1 컨트롤러의 종류와 핸들러 어댑터
스프링 MVC가 지원하는 컨트롤러의 종류는 4가지다.
- 각 컨트롤러를 DispatcherServlet에 연결해주는 핸들러 어댑터가 하나씩 있어야 하므로, 핸들러 어댑터도 4개다.
- 이 중에서 SimpleServletHandlerAdapter를 제외한 세 개의 핸들러 어댑터는 DispatcherServlet에 디폴트 전략으로 설정됨.
Servlet과 SimpleServletHandlerAdapter
- 첫 번째 컨트롤러 타입은 바로 표준 서블릿이다. 표준 서블릿 인터페이스인 javax.sevlet.Servlet을 구현한 서블릿 클래스를 스프링 MVC컨트롤러로 사용할 수 있다.
HttpRequestHandler와 HttpRequestHandlerAdapter
- HttpRequestHandler는 인터페이스로 정의된 컨트롤러 타입이다. 이 인터페이스를 구현해서 컨트롤러를 만든다.
Controller와 SimpleControllerHandlerAdapter
- SimpleControllerHandlerAdapter에 의해 실행되는 Controller 타입 컨트롤러는 위의 인터페이스를 구현해서 만든다.
- 컨트롤러는 DispathcerServlet이 컨트롤러와 주고받는 정보를 그대로 메소드의 파라미터와 리턴 값으로 갖고있다.
- 따라서 스프링 MVC의 가장 대표적인 컨트롤러 타입이다.
AnnotationMethodHandlerAdapter
- 컨트롤러의 타입이 정해져 있지 않음. 다른 핸들러 어댑터는 특정 인터페이스를 구현한 컨트롤러만을 지원한다.
- 반면에 AnnotationMethodHandlerAdapter는 컨트롤러 타입에 제한이 없다. 대신 클래스와 메소드에 붙은 몇가지 어노테이션의 정보와 메서드 이름, 파라미터, 리턴 타입에 대한 규칙 등을 종합적으로 분석해서 컨트롤러를 선별하고 호출 방식을 결정한다.
3.3.2. 핸들러 매핑
- 핸들러 매핑은 HTTP요청정보를 이용해서 이를 처리할 핸들러 오브젝트, 즉 컨트롤러를 찾아주는 기능을 가진 DispatcherServlet의 전략이다.
- 핸들러 매핑은 컨트롤러의 타입과는 상관없다.
- 하나의 핸들러 매핑 전략이 여러 가지 타입의 컨트롤러를 선택할 수 있다는 뜻이다.
- 디폴트 핸들러 매핑은 BeanNameUrlHandlerMappin과 DefaultAnnotationHandlerMapping이다.
BeanNameUrlHandlerMapping
- 빈의 이름에 들어 있는 URL을 HTTP요청의 URL과 비교해서 일치하는 빈을 찾아준다.
ControllerBeanNameHandlerMapping
- 빈의 아이디나 빈 이름을 이용해 매핑해주는 전략.
ControllerClassNameHandlerMapping
- 빈 이름 대신 클래스 이름을 URL에 매핑해주는 핸들러 매핑 클래스.
SimpleUrlHandlerMapping
- URL과 컨트롤러 매핑정보를 한곳에 모아놓을 수 있는 핸들러 매핑 전략.
- 매핑정보는 SimpleUrlHandlerMapping 빈의 프로퍼티에 넣어준다.
- 장점은 매핑정보가 한 곳에 모여 있기 때문에 URL을 관리하기 편하다는 것.
- 단점은 매핑할 컨트롤러 빈의 이름을 직접 적어줘야 하기 떄문에 오타 등 오류가 발생할 가능성 있음.
DefaultAnnotationHandlerMapping
- @RequestMapping이라는 어노테이션을 컨트롤러 클래스나 메서드에 직접 부여하고 이를 이용해 매핑하는 전략.
- 메서드 단위로 URL을 매핑해줄 수 있어서 컨트롤러 개수를 획기적으로 줄일수있음.
- 또한 URL뿐 아니라 GET/POST와 같은 HTTP메서드, 심지어 파라미터와 HTTP헤더정보까지 매핑에 활용가능.
- 같은 URL이지만 GET과 POST를 따로 분리하거나, 특정 파라미터가 지정됐을 때만 따로 분리하는 식의 컨트롤러 매핑이 가능.
- 다른 핸들러 매핑방식이라면 컨트롤러의 코드에서 처리해야 할 작업을 어노테이션으로 대신할 수 있어서 편리
- 반면 매핑 어노테이션의 사용 정책과 작성 기준을 잘만들지않으면, 개발자마다 제멋대로 매핑 방식 적용해서 매핑정보가 지저분해지고 관리하기 힘들어질 수 있다.
3.3.3.핸들러 인터셉터
- 핸들러 매핑의 역할은 기본적으로 URL과 요청정보로부터 컨트롤러 빈을 찾아주는 것이다.
- 한 가지 더 중요한 기능은 핸들러 인터셉터를 적용해주는 것.
- 핸들러 인터셉터는 DispatcherServlet이 컨트롤러를 호출하기 전과 후에 요청과 응답을 참조하거나 가공할 수 있는 일종의 필터.
핸들러 매핑의 또다른 역할 : 핸들러 실행 체인
- 핸들러 매핑의 역할은 URL로부터 컨트롤러만 찾아주는 것이 아니다.
- 핸들러 매핑은 DispatcherServlet으로부터 매핑 작업을 요청받으면 그 결과로 핸들러 실행 체인을 돌려준다.
- 이 핸들러 실행 체인은 하나 이상의 핸들러 인터셉터를 거쳐서 컨트롤러가 실행될 수 있도록 구성되어 있다.
- 핸들러 인터셉터를 전혀 등록하지 않으면 바로 컨트롤러가 실행됨.
- 반면 하나 이상의 핸들러 인터셉터 지정하면 순서에 따라 인터셉터 거친후에 컨트롤러 호출됨.
핸들러 인터셉트
- 핸들러 인터셉트는 HttpServletRequest,HttpServletResponse뿐 아니라, 실행될 컨트롤러 빈 오브젝트, 컨트롤러가 돌려주는 ModelAndView, 발생한 예외 등을 제공받을 수 있기 때문에 정교하고 편리하게 인터셉터만들 수 있다.
- 또한 핸들러 인터셉터 자체가 스프링 빈이기 때문에 DI를 통해 다른 빈활용가능.
HandlerInterceptor
- 핸들러 인터셉터는 HandlerInterceptor 인터페이스를 구현해서 만듬.
- 이 인터페이스 안에는 다음과 같은 세 개의 메서드가 포함되어 있다.
preHandle
- 컨트롤러 호출되기 전 실행
postHandle
- 컨트롤러 실행하고 난 후 호출됨
afterCompletion
- 모든 뷰에서 최종 결과를 생성하는 일을 포함한 모든 작업이 다 완료된 후에 실행
3.3.4.컨트롤러 확장
커스텀 컨트롤러 인터페이스와 핸들러 어댑터 개발
- 앞에서 Controller 인터페이스를 구현해서 만들었던 기반 컨트롤러 SimpleController를 이번에는 핸들러 어댑터를 이용해 호출 가능한 인터페이스로 정의해서 독자적인 컨트롤러 인터페이스로 만들어보자.
- 기존의 SimpleController는 모든 개별 클래스가 상속할 기반 클래스이므로 viewName이나 requiredParams 같은 공통 프로퍼티로 정의해놓을 수 있었다. 하지만 인터페이스로 정의하는 새로운 컨트롤러 타입에는 그런방식 사용 X.
- 그래서 대신 관례를 만들어서 비슷한 설정이 가능하게 해본다.
인터페이스를 이용하는 경우
- 어노테이션을 사용
- 어노테이션은 미리 약속된 관례를 따라서 특정 위치에 어노테이션을 부여해주고 엘리먼트 값을 이용해 설정 정보를 넣는 식으로 활용 가능.
SimpleController 인터페이스를 구현하고 두개의 설정용 어노테이션을 부여한 메서드를 가진 컨트롤러 HelloController.
- 뷰 이름과 필수 파라미터 목록은 어노테이션으로 지정한다.
- 모델 맵은 미리 만들어진 것을 전달 받아서 별도 생성 필요없이 정보 넣으면 됨.
- 이렇게 만들어진 HelloController 컨트롤러를 스프링 MVC에서 사용할 수 있도록 SimpleController 타입 컨트롤러를 지원하는 핸들러 어댑터를 만들어보자.
3.4 뷰
- 뷰는 MVC아키텍쳐에서 모델이 가진 정보를 어떻게 표현해야 하는지에 대한 로직을 갖고 있는 컴포넌트.
- 웹 환경에서 뷰가 생성하는 결과물은 일반적으로 브라우저에 나타낼 수 있는 HTML.
- 컨트롤러가 작업을 마친 후 뷰 정보를 ModelAndView타입 오브젝트에 담아서 DispatchServlet에 돌려주는 방법은 두 가지가 있다.
1. View 타입의 오브젝트를 돌려주는 방법
2. 뷰 이름을 돌려주는 방법.
2. 뷰 이름을 돌려주는 방법 (뷰 리졸버)
- 뷰 이름을 돌려주는 경우는 뷰 이름으로부터 실제 사용할 뷰를 결정해주는 뷰 리졸버가 필요하다.
- 뷰 리졸버가 처리하는 이런 뷰 이름을 '논리적인 뷰 이름'이라고 부르기도 한다. 논리적인 이름을 실질적인 뷰 오브젝트로 바꿔주기 때문.
3.4.1.뷰
- DispatchServlet이 사용하는 뷰 오브젝트는 스프링의 View 인터페이스를 구현해야 한다.
- View 인터페이스는
- 뷰 오브젝트가 생성하는 콘텐트의 타입 정보를 제공해주는 getContentType() 메서드와
- 모델을 전달받아 클라에 돌려줄 결과물을 만들어주는 render() 메서드,
- 두 가지로 구성된다.
- View 인터페이스를 직접 구현해서 뷰를 만들어야 할 필요는 없다.
- 스프링이 웹에서 자주 사용되는 타입의 컨텐트를 생성해주는 다양한 뷰를 이미 구현해놓았기 때문.
3.5 기타 전략
핸들러 예외 리졸버
- 컨트롤러의 작업 중에 발생한 예외를 어떻게 처리할지 결정하는 전략이다.
- HandlerExceptionResolver
지역정보 리졸버
- 애플리케이션에서 사용하는 지역정보를 결정하는 전략이다
- LocaleResolver
멀티파트 리졸버
- 파일 업로드와 같이 멀티파트 포맷의 요청정보를 처리하는 전략을 설정할 수 있다.
- CommonsMultipartResolver
3.6 스프링3.1의 MVC
플래시 맵 매니저 전략
- 플래시 애트리뷰트를 저장하는 맵이다.
- 플래시 애트리뷰트는 하나의 요청에서 생성되어 다음 요청으로 전달되는 정보를 말한다.
- 웹 요청 사이에 전달되는 정보라면 HTTP 세션을 생각할 수 있겠지만, 플래시 애트리뷰트는 일반 HTTP세션에 저장되는 정보처럼 오래 유지되지 않는다.
- 플래시 애트리뷰트는 다음 요청에서 한 번 사용되고 바로 제거되는 특징이 있다.
3.7 정리
- 스프링 애플리케이션의 웹 계층에는 스프링 MVC와 스프링 포트폴리오의 웹 기술 그리고 서드파티 웹 프레임워크를 모두 사용할 수 있다. 이를 위해 웹 계층과 나머지 계층 간의 의존관계를 제거하고 독립적으로 개발할 수 있어야 한다.
- 웹 계층의 테스트도 적절한 목 오브젝트를 이용한다면 서버에 배치하지 않고 자동으로 실행 가능ㅎ나 단위 테스트로 작성할 수 있다. 스프링은 웹 계층의 테스트를 위해 유용하게 쓸 수 있는 다양한 목 오브젝트를 제공한다.
- 스프링 MVC의 핵심 엔진인 DispatchServlet은 7가지 종류의 DI 가능한 전략을 제공한다. 각 전략은 빈으로 등록하고 설정할 수 있다. 직접 등록하지 않는 경우에는 디폴트 전략 구성을 활용한다.
- 컨트롤러는 여러가지 방식으로 개발할 수 있다. 핸들러 어댑터를 함께 만든다면 새로운 컨트롤러 타입을 추가할 수 있다.
- 핸들러 매핑은 다양한 전략을 통해 요청정보와 이를 처리하는 컨트롤러를 연결해준다.
- 핸들러 인터셉터는 컨트롤러를 실행하기 전후에 적용할 부가기능을 만들 때 사용한다.
- 뷰 리졸버는 컨트롤러가 리턴한 노닐적인 뷰 이름을 이용해 뷰 오브젝트를 찾아준다.
- 핸들러 예외 리졸버를 이용하면 애플리케이션에서 발생한 예외를 처리하는 방법을 지정해 줄 수 있다.
- 스프링3.1에는 플래시 맵 매니저 전략이 추가됐고 WebApplicationInitializer를 이용해 컨텍스트 생성과 등록을 위한 초기화 코드를 작성할 수 있다.
