티스토리 뷰
(참고: JSP/Servlet을 기준으로 작성된 글입니다)
Spring Framework
Spring MVC 또한 결국 스프링이 만든 하나의 Framework이다
즉 스프링이 만들어 놓은 DispatcherServlet, HandlerMapping 등의
인터페이스로 다형성을 활용하여 코드의 변경 없이 원하는 기능을 변경하거나 확장할 수 있는 것이다
스프링 프레임워크가 제공하는 주요 인터페이스부터 살펴보자
• DispatcherServlet
스프링 프레임워크의 핵심이라고 할 수 있는 디스패쳐 서블릿은 프론트 핸들러(컨트롤러) 패턴으로 설계되었다
프론트 컨트롤러가 없던 이전에는 한 개의 URL에 한 개의 서블릿이 매핑되는 구조를 사용하였다고 한다
이렇게 각각의 서블릿이 매핑이 되면 forward 같은 공통된 코드들이 매번 작성하여야 했고
또한 서블릿에 의존되기 때문에 순수한 자바코드의 단위 테스트가 불가능했다
각각의 핸들러에 직접 접근하는 이전 패턴과 달리 앞단의 공통 핸들러인 FrontHandler를 통해 요청에 맞는 핸들러를 찾아 호출하게 되면
이를 통해 각각의 핸들러에서는 서블릿을 별도로 사용하지 않아도 되며 공통 코드를 작성할 수 있게 됨으로써 유지보수의 효율성이 높아진다
사용자에게 받은 요청은 핸들러를 호출하기 위해 핸들러 매핑으로 넘어가게 된다
• HandlerMapping
요청 URL을 처리할 수 있는 테이블을 만든다
즉 클래스에 @RequstMapping annotation(또는 WebServlet도 있으나 사용하지 않음)을 정의하면
해당 URL에 대한 요청이 들어왔을 때 테이블에 저장된 정보(URL)에 따라 해당 클래스 또는 메서드를 매핑한다
정의한 URL은 아래와 같은 우선순위를 기준으로 매핑된다
0 = RequestMappingHandlerMapping : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용
1 = BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러를 찾는다.
• ViewResolver
핸들러가 반환한 논리 이름(the logical names)에 prefix, suffix를 적용하여 물리 이름(the physical view files)을 반환한다
예를 들어 아래와 같이 jsp 파일이 존재한다면 여기서 논리 이름은 ' example ' , 물리이름은 ' /WEB-INF/views/example.jsp ' 가 된다
ViewResolver는 개발자가 작성한 prefix & suffix 규격에 맞춰 핸들러에게 받은 모델을 전달한다
//spring boot 기준, application.properties에 작성
spring.mvc.view.prefix=/WEB-INF/views/
spring.mvc.view.suffix=.jsp
• View
ViewResolver를 통해 전달받은 모델은 해당 View에서 Model data를 이용하여 적절한 페이지를 만들어 사용자에게 응답된다
Spring MVC Architecture의 동작 방식
1. HTTP 요청
2. Handler 조회
핸들러 매핑을 통해 요청 URL에 매핑된 핸들러를 조회한다
3. Handler 어댑터 조회
핸들러 어댑터라는 중간 역할은 다양한 종류의 핸들러를 호출할 때 그에 맞는 핸들러를 호출할 수 있도록 도와주는 역할을 한다
예시로 우리가 일상생활에서 사용하는 콘센트 어댑터를 생각하면 이해하기가 조금 더 편하다
우리나라와 다른 표준전압을 사용하는 국가에 가면 핸드폰을 충전하려 할때 콘센트의 구멍이 달라 어려움을 겪는 경우가 있다
이때 V110 콘센트를 V220 콘센트로 전압을 변환 해주는 어댑터를 사용하는 것과 매우 유사하다
핸들러를 실행할 수 있는 핸들러 어댑터는 아래와 같은 우선순위를 기준으로 조회하여 호출된다
0 = RequestMappingHandlerAdapter : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용
1 = HttpRequestHandlerAdapter : HttpRequestHandler 처리
2 = SimpleControllerHandlerAdapter : Controller 인터페이스(애노테이션X, 과거에 사용) 처리
4. Handler 어댑터 호출
핸들러 어댑터를 실행한다
5. Handler 호출
핸들러 어댑터가 실제 핸들러를 실행한다
6. ModelAndView 반환
핸들러 어댑터는 핸들러가 반환하는 정보를 ModelAndView로 변환해서 반환한다
7. ViewResolver호출
뷰 리졸버를 찾고 실행한다
8. View
뷰 리졸버는 뷰의 논리 이름을 물리 이름으로 바꾸고, 렌더링 역할을 담당하는 뷰 객체를 반환한다
9. HTML 응답
뷰를 통해서 렌더링한 후 응답한다
핵심정리
Spring MVC Framework는 기존 각각의 URL이 매핑되던 기존 핸들러 패턴에서
프론트 핸들러 패턴(디스 패쳐 서블릿)을 도입함으로써 공통의 로직을 한 곳에서만 작성하게 만들어주었다
또한 각각의 핸들러가 서블릿에 의존되지 않음으로써 단위 테스트를 가능케 했다
디스 패쳐 서블릿을 통하여 들어온 요청은 핸들러 매핑과 핸들러 어댑터를 사용하여
각기 다른 요청에 해당 핸들러를 호출할 수 있게 만들었고
이렇게 호출되어 실행된 핸들러는 ModelAndView를 반환하며
ViewResolver를 통해 View를 렌더링 하여 클라이언트에게 응답한다
개인 학습을 위해 작성되는 글입니다.
제가 잘못 알고 있는 점에 대한 지적 / 더 나은 방향에 대한 댓글을 환영합니다.
참조 링크:
https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard
https://gmlwjd9405.github.io/2018/12/20/spring-mvc-framework.html
'Spring > Spring MVC' 카테고리의 다른 글
[Spring MVC] HTTP Message Converters (HTTP 메시지 컨버터) (0) | 2021.08.28 |
---|---|
[Spring MVC] Argument Resolver와 ReturnValue Handler (0) | 2021.08.27 |
[Spring MVC] Request Mapping 과 REST API 설계 (0) | 2021.08.24 |
[Spring MVC] @Controller 와 @RestController (0) | 2021.08.24 |
[Spring MVC] MVC Architecture (0) | 2021.08.21 |
- Total
- Today
- Yesterday
- 제이쿼리 탐색선택자
- spring
- DTO와 VO의 차이
- @ResponseStatus
- @ExceptionHandlere
- 제이쿼리 직접 선택자
- Cache
- 쿠키
- 제이쿼리 위치탐색선택자
- uri
- DefaultHandlerExceptionResolver
- 제이쿼리 인접 관계 선택자
- ResponseStatusExeceptionResolver
- 맨코
- Spring API Error
- Spring TypeConverter
- maenco
- OOP
- jQuery 직접 선택자
- cookie
- 캐시
- Session
- 세션
- Spring MVC
- http
- Spring Container
- application/x-www-form-urlencoded
- 제이쿼리란
- 제이쿼리 기본 선택자
- ExceptionHandlerExceptionResolver
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |