토비의 스프링 13장 - 스프링 웹 기술과 스프링 MVC

클라이언트 시스템과 연동하는 책임을 맡고 있는 것이 바로 웹 프레젠테이션 계층

스프링은 기술의 변화가 잦은 웹 계층과 여타 계층을 깔끔하게 분리해서 개발하는 아키텍처 모델을 지지한다.

스프링 서블릿/스프링 MVC

프론트 컨트롤러 역할 Dispatcher Servlet

모든 컴포넌트는 서블릿 애플리케이션 컨텍스트의 빈으로 등록되어 동작함

Spring web flow → stateful 스타일의 웹 애플리케이션을 작성하게 해주는 프레임워크

수십여 가지의 자바 웹 프레임워크가 존재하며, 그중 상당수는 스프링과의 손쉬운 연동 기능을 제공해준다.

스프링이 직접 제공하는 웹 프레임워크 사용추천 - 스프링 MVC

13.1.2 두 가지 방향으로 발전하고 있음

1. 유연성과 확장성에 중점을 두고 어떤 종류의 시스템 개발이나 환경, 요구조건에도 잘 들어맞도록 재구성할 수 있는 범용적 프레임워크 ⇒ 기술 사이의 독립성, 서비스 추상화와 같은 방식으로 최대한 느슨하게 연결해서 의존성이 발생하지 않도록 만듬 ⇒ 장기적으로 많은 인원이 큰 규모의 시스템을 개발할 때 적합
2. 일체형 고속개발 프레임워크. 제한적인 기술만을 사용하도록 강제. 대신 특정 기술의 장점을 극대화하도록 설계됨

→ 스프링은 유연성과 확장성, 다양성에 무게를 두고 있는 프레임워크

MVC → 모델, 뷰, 컨트롤러

프론트 컨트롤러 패턴 = 중앙집중형 컨트롤러를 프레젠테이션 계층의 제일 앞에 둬서 서버로 들러오는 모든 요청을 먼저 받아서 처리하게 만든다.

클라이언트가 보낸 요청을 받아서 공통적인 작업을 수행한 후에 적절한 세부 컨트롤러로 작업을 위임해주고, 클라이언트에게 보낼 뷰를 선택해서 최종 결과를 생성하는 등의 작업을 수행

DispatcherServlet = 프론트 컨트롤러 → 프레젠테이션 계층을 만들 수 있도록 설계

URL 정보, 파라미터 정보, HTTP 명령(GET,POST ..) 를 확인하여 어떤 컨트롤러에게 작업을 위임할지 결정함( 핸들러(컨트롤러) 매핑 전략)

전략 패턴 → Dispatcher Servlet의 확장 없이도 DI를 통해서 확장 가능

어떤 URL이 들어오면 어떤 컨트롤러 오브젝트가 이를 처리하게 할지를 매핑해주는 전략을 만들어서 DI로 제공해주기만 하면 된다.

컨트롤러 메서드를 어떻게 호출할지를 알고 있어야 한다.

DispatcherServlet은 어떤 종류의 오브젝트라도 컨트롤러로 사용할 수 있다. 무한한 확장성의 비결

오브젝트 어댑터 패턴 → 해당 컨트롤러 타입을 지원하는 어댑터를 중간에 껴서 호출

어댑터 → 자신이 담당하는 컨트롤러에 맞는 호출 방법을 이용해서 컨트롤러에 작업 요청을 보내고 결과를 돌려받아서 DispatcherServlet에 돌려주는 기능을 가지고 있다.

어댑터는 HttpServletRequest, HttpServletResponse를 전달받고, 그것을 사용하여 컨트롤러에서 사용될 값의 타입으로 돌려줌

컨트롤러의 작업

→ 1. 사용자의 요청을 해석

1. 실제 비지니스 로직을 수행하도록 서비스 계층 오브젝트에게 작업을 위임하는것
2. 1. 결과를 받아서 모델을 생성하는 것( 그러나 요즘은 RestController를 사용하여 json을 돌려줌)
3. 어떤 뷰를 사용할지 결정하는 것

모델과 뷰 (ModelAndView)

• 모델이 준비됐으면 뷰를 결정할 차례
• 뷰의 논리적인 이름 → DIspatcherServlet이 뷰 오브젝트
• 컨트롤러가 DispatcherServlet에게 ModelAnView(모델과 view) 정보를 돌려줌

HandlerMapping

• URL과 요청 정보를 기준으로 어떤 핸들러 오브젝트, 즉 컨트롤러르 사용할 것인지를 결정하는 로직을 담당

디폴트로 BeanDNameUrlHandlerMapping, DeafultAnnotationHandlerMapping이 설정되어있음

→ 핸들러 매핑을 구현하여 추가할 수 있음

HandlerAdapter

→ 핸들러 매핑으로 선택한 컨트롤러/핸들러를 DispatcherServlet이 호출할 때 사용하는 어댑터. 기본적으로 등록되어 있는 핸들러 어댑터는 HttpRequestHandlerAdpater, SimpleControllerHandlerAdapter, AnnotationMethodHandlerApter.

핸들러 매핑과 어댑터는 서로 관련 있을 수도 있고 없을 수도 있음.

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

각각 하나만 쓰일수도 있고, 여러개씩 쓰일수도 있음

RequestMapping과 Controller 애노테이션은 한가지 컨트롤러에 의해서 결정됨

HandlerExceptonResolver

예외가 발생했을 때, 이를 처리하는 로직을 가지고 있음

LocaleResolver

→ 지역 정보를 결정해줌

Http HEader의 정보로 들어온 locale 정보를 활용할 수 있음

ThemeResolver

→ 자주 사용하지는 않지만, 테마를 설정할 수 있음

3.2 스프링 웹 애플리케이션 환경 구성

HttpSession, ServletContext, Http 쿠키, Http 헤더 등도 전달해줄 수 있음

? 에 담긴 것을 HttpReqeuest에 key ,value로 넣어줌

만약 name, value에 같은 것이 있다면 그것에 매핑시켜줌

테스트: MockServletRequest, MockServletResponse

Controller를 서버에 배치하지 않고 JUnit을 사용하여 단위 테스트를 만들기

→ ConfigurableDIspatcherServlet

ModelAndView를 사용하는 경우에는 완전 적합해 보임..

→ RestController의 경우에도 사용할 수 있을까?

3.3 컨트롤러

파일 - multipart 로 업로드

• 첫번째 컨트롤러 타입은 표준 서블릿

13.3.3 핸들러 인터셉터

• 핸들러 실행 체인을 돌려줌

PreHandle - 컨트롤러 실행전

PostHandle - 컨트롤러 실행후, 컨트롤러가 돌려준 ModelAndView에 작업을 조작할 수 있음