[강의 정리] 스프링 MVC 설정(2)

강의 출처: https://www.inflearn.com/course/%EC%9B%B9-mvc/dashboard

스프링 웹 MVC 강의 - 인프런

---

 

👩‍💻 WebMvcConfigurer

 

✅ Formatter

 - 어떠한 객체를 문자열로 변환하거나, 어떠한 객체로 변환하기 위해 사용하는 인터페이스

 - Formatter를 사용하면, http 요청 문자열을 객체로 변환하여 받을 수 있다

 - Printer : Locale 정보를 참고하여, 해당 객체를 문자열로 어떻게 출력해 줄 것인지 정의

 - Parser : Locale 정보를 참고하여, 어떤 문자열을 객체로 어떻게 변환할 것인지 정의

 

 

🐥 Formatter 구현

@GetMapping("/hello/{name}")
public String hello(@PathVariable("name") Person person){ }

 - 파라미터 name을 Person 객체로 받고 싶을 때, formatter 클래스를 구현해야 함

 - PathVariable 뿐만아니라 RequestParam이어도 formatter 적용됨

 

public class PersonFormatter implements Formatter<Person> {

	// 문자열 -> 객체
	@Override
	public Person parse(String text, Locale locale) throws ParseException {
    	Person person = new Person();
        person.setName(text);
        return person;
	}
    
	// 객체 -> 문자열
	@Override
	public String print(Person object, Locale locale) {
		return object.toString();
	}
}

 

 

구현한 formatter 적용법: 프로젝트의 WebConfig 클래스 WebMvcConfigurer을 구현받도록 하고,

    `void addFormatters(FormatterRegistry registry);` 를 구현

 

FormatterRegistry에는 formatter뿐만아니라 converter도 추가할 수 있음

Converter: 문자열 아닌 객체 -> 다른 객체로 변환하도록 해주는 좀 더 일반적인 범위 다룸 ㅇㅇ

 

 

 

스프링부트에서는 Formatter를 빈으로 설정해주기만 하면,

addFormatters() 메서드를 통해 따로 추가해주지 않아도 적용된다.

 

 

👩‍💻 도메인 클래스 컨버터

 - spring data jpa가 제공하는 스프링 mvc용 도메인 클래스 컨버터

 - 그래서 도메인을 포매팅 또는 컨버팅 하기 위해서 포매터를 따로 정의, 설정하지는 않아도 된다.

 - 컨버팅을 위해서는 JpaRepository 인터페이스를 정의해야 한다.

 

 

👩‍💻 핸들러 인터셉터

 - 핸들러 인터셉터로 핸들러 맵핑에 어떠한 설정을 해줄 수 있다.

 - 핸들러 맵핑은 핸들러를 찾아서, 그 핸들러에게 인터셉터를 적용해준다

 - 핸들러를 실행하기 전, 핸들러 실행 후 랜더링 하기 전, 랜더링까지 끝난 이후 시점에  사용한다.

preHandle -> 요청 처리 -> postHandler -> 뷰 랜더링 -> afterCompletion

 

 

✅ preHandle

default boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
			throws Exception {

		return true;
	}

 

 - 실행 시점: 핸들러 매핑에서 핸들러 찾은 후, 핸들러 어댑터가 핸들러를 호출하기 전

 - 리턴값: 계속 다음 인터셉터 또는 핸들러로 요청과 응답을 전달할지(true), 응답처리가 이곳에서 끝났는지(false) 알림

 

✅ postHandle

default void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler,
			@Nullable ModelAndView modelAndView) throws Exception {
	}

 

 - 실행 시점: 핸들러 실행이 끝난 이후, 디스패처 서블릿이 뷰를 랜더링 하기 이전

 - 파라미터로 ModelAndView 를 받으니까, postHandle에서 ModelAndView를 커스텀 할 수 있다.

 - 모델에 추가 정보 적는다거나, 뷰를 변경한다거나, 여러 핸들러에 공통적인 모델 정보를 담는데 사용할 수도 있다

 

 - 핸들러 인터셉터가 여러 개일 경우, 역순으로 호출된다.

만약 interceptor1 -> interceptor2 -> interceptor3 순으로 체이닝 되어 있다면

interceptor1.preHandle() -> interceptor2.preHandle() -> interceptor3.preHandle() -> handler -> interceptor3.postHandle() -> interceptor2.postHandle() -> interceptor1.postHandle() 순으로 호출됨

 

 

 - 비동기 요청 처리시에는 호출되지 않는다.

 

✅ afterCompletion

default void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler,
			@Nullable Exception ex) throws Exception {
	}

 

 

 - 실행 시점: 뷰 랜더링 이 끝난 이후

 - 마찬가지로 인터셉터가 여러 개인 경우, 역순으로 호출된다.

 - 비동기 요청 처리 시에는 호출되지 않는다.

 

 

✅ 서블릿필터와의 차이점?

 

 - 핸들러 인터셉터가 조금 더 구체적인 정보(핸들러 객체, 모델앤뷰)를 받아 사용한다.

 

 - 스프링에 특화된 정보(핸들러 등)와 아무런 관련이 없는 일반적인 기능은 서블릿필터로 구현해야 한다

    - 예를들면 xss(cross-site scripting) 차단기능

 

 - 참고로 서블릿필터 설정 : web.xml 또는 WebAppInitializer에

 

✅ 구현한 인터셉터 설정

 - WebConfig 파일에 설정

 - 별도 설정 없으면 레지스트리에 추가한 순서대로 체이닝된다.

 

 - 명시적으로 순서 지정해주는법:

registry.addInterceptor(new GreetingInterceptor()).order(-1);
registry.addInterceptor(new AnotherInterceptor()).order(2);

 

    - order 값의 숫자가 작을수록 먼저 호출된다.

 

 

 - 원하는 특정 패턴에만 적용하는법: .addPathPatterns("패턴")

 

 

👩‍💻 리소스 핸들러

 

✅ 리소스 핸들러

 - 정적인 리소스(이미지, JS, CSS, HTML, 파일 등)를 처리하는 핸들러

 - 핸들러들 중 우선순위가 가장 낮음

 

 

✅ Default Servlet

 - 서블릿 컨테이너가 기본으로 제공하는 서블릿

 - 정적인 리소스를 처리함

 - 톰캣은 이 default servlet에 정적인 리소스 요청을 위임해서 처리하도록 한다.

 

 

스프링부트는 기본적으로 정적인 리소스 핸들러의 캐싱을 제공: resources/static 디렉토리

 

 

 

✅ 리소스 핸들러 설정 (커스텀 리소스 핸들러)

 

 

이거 듣다가 캐시 관련 내용 공부도 했음 - https://catromi.tistory.com/323

 

 

👩‍💻 HTTP 메시지 컨버터

 

 - @RequestBody에서 요청 본문을 객체로 바꿀 때, 그리고 @ResponseBody에서 객체를 요청 본문에 넣어줄 때

    HTTP 메시지 컨버터를 사용한다

 - 스프링이 4개의 기본 컨버터를 등록한 다음, Classpath를 보고 필요한 메시지 컨버터들을 등록해준다

 - 어떤 메시지 컨버터를 사용할지는 요청 헤더의 Content-type을 보고 결정한다

 

 

✅  WebConfig 설정

 

 - configureMessageConverters 오버라이딩

    - 이 메서드를 오버라이딩하면, 4개의 기본 컨버터들은 등록되지 않게 된다.

 

 - 4개의 기본 컨버터도 사용하고, 다른 메시지 컨버터를 추가하고 싶은 경우라면

    extendMessageConverters 오버라이딩 해야한다.

 

 

👩‍💻  JSON용 http 메시지 컨버터

 

WebMvcConfigurationSupport에서

 

필요한 메시지 컨버터만 등록해주기 위해서 각 라이브러리 의존성이 추가되었는지 확인하고

 

 

기본 4개 컨버터 이외의 나머지 컨버터들은

필요하면 등록해준다

 

 

메시지 컨버터는 메시지 컨버터와 함께 등록되는 ObjectMapper를 사용해서 `http 메시지 본문 <-> 자바` 객체 간 변환 해준다.

 

요청 헤더 Content-type 이 json이라고 명시되어 있으니

이걸 보고 json converter를 사용해 변환하게 된다.

 

 

👩‍💻 그 외 WebMvcConfigurer 설정

 

✅ ArgumentResolver 

 - 컨트롤러에서 기본적으로 지원해주는 argument 외의 인자들도 커스터마이징해서 추가할 수 있음

 - Argument들을 어떻게 인식, 처리할지 스프링에게 알려주기 위해서 argumentResolver 추가

 

✅ 뷰 컨트롤러 

 - 핸들러 구현하지 않고도, 단순하게 요청 URL을 특정 뷰로 연결하고 싶을 때 사용할 수 있다.

 

 

 

 

👩‍💻 스프링 MVC 설정 최종 정리

 - 스프링 MVC 설정은 결국 DispatcherServlet이 사용할 모든 빈들을 ApplicationContext에 등록, 설정하는 것이다.

@EnableWebMVC

 - 하나하나 등록 및 설정하자니 너무 번거로워서 , 스프링 MVC 설정을 간편화하기 위해서 사용

 - 어노테이션 기반의 스프링 웹 MVC 설정을 도와줌

 - WebMvcConfigurer 인터페이스가 제공하는 메서드를 오버라이딩하여 여러 설정을 커스터마이징 할 수 있다.

 

 

스프링 부트를 쓴다면

 - 스프링부트는 자동 설정을 통해, 아무런 설정 파일을 만들지 않아도 다양한 스프링 MVC 기능을 제공

 - 스프링부트 프로젝트에서 @EnableWebMvc를 사용하면, 스프링부트 자동 설정을 사용하지 못한다.

 - 스프링부트 프로젝트에서는 application.properties를 통해 스프링 MVC 설정을 한다.

- 또는 WebMvcConfigurer 메서드를 오버라이딩하여 설정한다