5장

요청이 브라우저를 떠나 디스패처 서블릿에 도착  요청URL을 분석하기위해 핸들러 매핑의 도움을 받는다  핸들러 매핑에 정보를 이용하여 URL과 비교하여 맞는 컨트롤러에게 전달

단일 프론트컨트롤러 : 디스패처 서블릿  

Servlet & jsp로 구현할때와는 다르게 스프링MVC 에서는 모든 요청을 디스패처서블릿이 처리한다

디스패처 서블릿 : 요청에맞는 스프링 MVC 컨트롤러에게 전달함

컨트롤러 : 요청을 처리하는 컴포넌트

컨트롤러에 요청이 도착하면 사용자가 요청한 정보를 컨트롤러에게 전달 컨트롤러가 그것을 처리할때까지 기다린다

Model : 컨트롤러가 요청을 처리한후 사용자가 읽을수있는 정보로 변환

컨트롤러가 처리한 정보를 Model로 만든후 전달한다 

하지만 Model 자체를 넘기는건 좋지않다 HTML 같은 사용자가 보기편한것으로 변환하여 전달한다

그렇게 하기위해서는 JSP(Java Server Page) 같은 View가 필요하다

컨트롤러가 마지막으로 하는일은 Model을 패키징 하는것과 결과물을 렌더링 하기위한 뷰 이름을 확인하는것 

이것을 다 처리한후 Model과 View를 디스패처 서블릿에게 돌려보낸다

여기서 View는  jsp인지 html인지 그런것에 종속되어있지않는다 단순히 이것을가지고 실제 값을 찾을수있도록 도와주는것뿐

Model과 View를 받은 디스패처 서블릿은 view이름을 가지고 실제 뷰와 매핑되도록 View Resolver에게 보낸다

View Resolver가 매핑해준 view를 가지고 이제 model을 이용하여 렌더링해주고 응답객체에 의해 클라이언트에게 전달된다

과거에는 web.xml에 디스패처 서블릿을 정의하였지만 이젠 java로 설정한다

AbstractAnnotationConfigDispatcherServletlnitializer 를 상속받은 Initializer에 설정한다

getServletMappings 에 디스패처 서블릿을 매핑하고

RootConfing = ApplicationContext

WebConfig = web.xml 

스프링은 SpringServletContainerlnitializer의 구현을 제공하고 이것은 순차적으로 WebApplication Initializer의 구현 클래스를 찾아 설정을 위임한다. 

스프링 3.2에서는 AbstractAnnotationConfigDispatcherServletlnitializer라고 하는 

WebApplicationlnitializer의 편리한 기본 구현이 제공된다. 

SpittrWebAppInitializer 역시 AbstractAnnotationConfigDispatcherServletlnitializer(이것은 WebApplicationlnitializer를 구현)를 상속받아 구현한 것이므로 서블릿 3.0 컨테이너에서 배포될 때 자동 적으로 발견되어 서블릿 컨텍스트를 자동 초기화한다

AbstractAnnotationConfigDispatcherServletlnitializer은 디스패처서블릿과 ContextLoaderListener를 생성한다

getServletConfigClasses 에서 리턴된 @Configuration이 붙은 설정 클래스들은 디스패처 서블릿이 만든 어플리케이션 컨텍스트에 채워지고 

getRootConfigClass 에서 리턴된 @Configuration이 붙은 설정 클래스들은 ContextLoaderListener가 만든 어플리케이션 컨텍스트에 채워진다

AbstractAnnotationConfigDispatcherServletlnitializer을 이용해 디스패처 서블릿을 설정하는것은 web.xml의 대안임을 아는것이 중요하다

AbstractAnnotationConfigDispatcherServletlnitializer에 web.xml을 포함하여 설정할수도있지만 하지않아도 된다

AbstractAnnotationConfigDispatcherServletlnitializer을 사용한 디스패처서블릿을 설정방식의 유일한 맹점은 톰캣 7(혹은 그 이상의 버전)과 같이 서블릿 3.0 이상을 지원하는 서버에 배포될 때만 동작한다는 점이다

서블릿 3.0 가능 서버에서 작업을 하고 있지 않다면 DispatcherServlet을 AbstractAnnotation ConfigDispatcherServletlnitializer로 설정하면 안 되므로 web.xml으로 설정한다

스프링 MVC 컴포넌트를 활성화하는 방법

1. XML로 할떄는 <mvc:annotation driven> 을 사용

2. java로 할떄는 @EnableWebMvc를 붙여준다

위와 같이 설정 클래스를 작성한다음 디스패처 서블릿이 컨트롤러를 찾을수있게 해주는것과 뷰리절버를 등록하여 실제 뷰와 매핑시켜주는것과 css 등 컨트롤러 이외의 파일을 처리하는 디폴트 서블릿이 필요하다

@ComponentScan은 스캔될 대상의 클래스에 @Controller를 붙여주면 스캔된다

ViewResolver 빈이 추가된다 prefix는 앞에부분 suffix는 뒤에부분으로  뷰이름 가지는 jsp파일을 찾아주는 JSP View Resolver 이다

그다음은 디폴트 서블릿을 설정해준것이다

RootConfig도 컴포넌트스캔을 이용한다 패키지는 spitter패키지 Filter는 스캔을 제외할 class를 설정

간단한 컨트롤러이다 

@Controller가 붙음으로써 @ComponentScan에 의해서 자동으로 어플리케이션 컨텍스트에 빈으로 채워진다

@RequestMapping의 value는 처리할 요청path를 나타내고 method는 처리할 http메소드를 명시한다

위와같은경우는 value가 / 로 잡혀있기때문에 모든 요청을 받고 get으로 받는다

home String 값으로 논리적인 값을 전달해주고 그것을 이용하여 실제 view와 매핑된값으로 view Resolver에게 전달받는다

InternalResourceViewResolver로 인해 /WEB-INF/view/home.jsp 파일로 결정된다

스프링 3.2부터  스프링 MVC 컨트롤러를 테스트할수있다

 이 테스트는 HomeController의 인스턴스를 MockMvcBuilders.standaloneSetup으로 전달해 주고 MockMvc 인스턴스를 만들어 주기 위해 build()를 호출해 주는 것으로 시작한다

그리고 MockMvc 인스턴스에 "/"에 대한 GET 요청을 처리하도록 요청하고 뷰 이름에 대한 기대 값을 설정한다 

@RequestMapping 분할 방법

"/" path가 클래스레벨로 올라가있다 이렇게하면 이 컨트롤러에 들어오는 모든 path에는 /가 있어야한다

클래스 레벨의 RequestMapping은 모든 핸들러 메소드에 적용된다

위와같이 클래스레벨의 RequestMapping을 여러개 해줄수있다 여러개를 할시에는 {} 괄호가 필요

핸들러메소드에 데이터를 전달하는 방법

1. 쿼리 파라미터

2. 폼 파라미터

3. 패스 변수

쿼리 파라미터 (@RequestParam)

-  클라이언트가 서버로 정보를 전달하는 가장 쉽고 간결한 방법

RequestParam에 값이 들어오지않으면 에러가 발생한다 그래서 defaultValue를 설정해야한다

max에 값이 오지않으면 defaultValue로 Long의 가장 높은값을 설정하였고 count에 값이오지않으면  defaultValue로 20을 설정하였다

패스 파라미터로 입력받기

위의 spittle_id값은  /spittles/show?spittle_id=12345 이와 같은 방식으로 요청한다

쿼리파라미터는 /spittles/show/12345      일반적으로는 쿼리파라미터는 리소스를 식별하지않는다

/spittles/show/12345 이 방식이 /spittles/show?spittle_id=12345  이 방식보다 좀더 나은 GET 

요청방식이다

전자의 방식은 리소스를 식별한다

value=/{spitID}  이와같은것을 패스 플레이스 홀더라 한다 

패스 플레이스 홀더를 사용하면 이것을 받아주기위한 @PathVariable이 필요하다

@PathVariable long spitID로 세팅해두면 spitID값으로 들어온것이 pathVariable의 값으로 자동으로 세팅된다

@PathVariable의 변수명과 패스 플레이스 홀더의 변수명은 반드시 일치해야한다

폼 처리하기

폼을 처리하는 방식은 2가지

1. 폼 보여주기

2. 폼을 통해 사용자가 보낸 데이터 처리하기

간단하게 논리적인 뷰 이름을 리턴해주는 핸들러메소드 뷰 리절버에 의해 실제 registerForm.jsp 파일과 매핑되어 폼을 보여준다

위 jsp는 반드시 form 태그가 포함되어있어야한다

테스트 코드

폼 화면 보여주기는 get 

데이터 받아서 처리하는건 post  리다이렉트를 해줘야한다

리다이렉트를 해주지않으면 사용자가 보낸 form에 데이터가 그대로 남아있기때문에 똑같은 데이터가 또 들어올 위험이있다

redirect를 뷰 리절버의 prefix나 suffix로 등록을 해두면  사용자의 프로파일쪽으로 리다이렉션된다 

폼 검증하기

특정 파라미터값을 안주거나 너무길때 검증처리를 한다

스프링에서 제공하는  자바 인증(Validation) APK(a.k.a JSR-303)을 사용

3.0 버전부터 스프링 MVC에 자바 인증 API가 지원되기 시작했다

자바 인증 API는 프로퍼티의 값에 제약을 두기 위한 몇 가지 애너테이션을 정의

모든 애너테이션들은 javax.validation.constraints 패키지에 들어 있다

주로 사용하는건 @NotNULL, @Size

위와 같이 사용

사용자가 반드시 등록 폼의 모든 필드에 길이 제약에 맞추어 값을 넣어 주어야 한다는 것을 의미한다

@Valid 를 붙이면 사용자로 부터 받은 데이터 spitter객체의 입력을 검증한다

error 발생시 폼으로 되돌아가며 error를 전달한다

Errors errors가 @Valid 밑에 와야 작동한다 

Model같은것은 @Valid 위에 작성해야한다 그렇지않으면 @Valid에 의해 검증되기때문에