이미 실무에서 사용하여 사용법이 익숙하고 사용을 계속 하면서부터 대충 스프링 MVC가 이런 역할을 대신 해주고 있겠구나 라고 생각은 했지만
공부를 제대로 하면서 애매하게 알던 부분들이 잘 정리되었고 원리를 알게됨과 동시에 아키텍처 관점에서의 시야도 더욱 넓어지게 되었다.
거기에 탄생배경까지 알게 되니 Spring MVC가 대신 해주는 일들이 얼마나 고마운 일인지도 다시 한 번 생각하게 되었다.
공부를 완료한 기념으로 생각나는대로 복습하는 내용을 끄적여본다.
- Spring MVC탄생 배경
WAS에서 사용자의 요청 정보를 받아 Servlet에 넘겨준다.
request객체를 넘겨받은 Servlet에서는 요청 정보를 꺼내 요청을 처리하고 결과를 Reponse에 담아 응답한다.
많은 일을 하는 Servlet의 역할의 분리를 위해 Model-View-Controller 패턴이 탄생하게 되었다.
Controller에서 요청을 받아 어플리케이션 핵심로직에 요청을 위임하여 얻은 반환값은 Model에 담아 View에 넘겨주면, View는 데이터를 가지고 사용자에게 보여줄 화면을 렌더링한다.
MVC 패턴의 도입으로 이전보다 유지보수성이 증가한 어플리케이션을 만들 수 있었으나
그 과정에서 Controller에서는 여전히 request에서 요청정보를 꺼내고 response를 담아 넘겨주는 단순 작업이 반복된다는 문제는 여전히 남아있었다.
이를 개선하기 위해 Controller 이전에 하나의 Controller를 더 배치시켜 단순 반복되는 작업을 줄여주는 Front-Controller 패턴이 등장하게 되었고 이후 Spring에서도 이 패턴을 적용한 Spring MVC프레임워크를 탄생시키게 된다.
- 원리
Was가 FrontController에게 request정보를 넘겨준다. (FrontController를 Spring에서는 Dispatcher Servlet이라 한다.)
FrontController는 요청을 처리할 핸들러를 찾고, 그 핸들러에 맞게 파라미터와 응답 처리를 대신 해줄 핸들러 어댑터를 찾아 어댑터에게 request와 response, handler를 넘겨준다.
request를 전달받은 핸들러 어댑터는 자신이 담당하는 핸들러가 원하는 파라미터를 만들어 핸들러를 호출하고, 핸들러의 결과 데이터를 Response에 담는다.
핸들러 어댑터가 파라미터를 생성할 때에는 Argument Resolver를 사용하고, 응답할 때에는 ReturnValue Handler를 사용하며, 각 resolver와 handler는 데이터 변환 과정에서 content-type과 client의 accept헤더 등의 정보를 통해 알맞는 Message Converter를 호출하여 데이터를 변환한다.
- 요청 시 데이터 전달 방식
client가 Server로 요청을 날릴 때 요청 데이터를 보낼 수 있는 방법은 세 가지가 있다.
1) Get 방식에서는 쿼리스트링(최근에는 request body에도 데이터를 넣을 수 있도록 지원해준다고 한다.)을 사용한다.
이를 Controller는 @RequestParam(생략가능)을 사용하여 사용자의 쿼리스트링 데이터를 전달받을 수 있다.
Get 방식에서의 쿼리스트링 데이터가 객체의 필드라면 @ModelAttribute(생략가능)을 사용하여 하나하나의 파라미터가 아닌 완성된 객체 형태로 받을 수 있다.
2) Post 메소드를 이용하여 form 제출할 때에도 쿼리 스트링 방식을 사용하여 동일하게 @RequestParam, @ModelAttribute를 이용하여 데이터를 전달받을 수 있는데, Get방식과는 달리 request body에 담겨 데이터가 들어온다는 차이가 있다.
3) Post, Put, Patch 방식에서는 request body에 데이터를 넣어(주로 Json형태) 전달한다. @RequestBody를 사용하여 객체로 변환된 데이터를 바로 전달받을 수 있다.
- 응답 시 데이터 전달 방식
1) 정적 리소스 (WS가 알아서 전달)
2) HTML 응답 방식
3) 데이터 직접 전달(API 방식)
