기존의 방식
위의 문제들이 있으니 MVC 패턴을 도입하게된 결정적인 이유가 되었음
Controller와 View의 영역을 나눈 모습!
exceptional)
물론 Controller에 비즈니스 로직을 정의하여 사용할 수 있지만, 그렇게 되면 또 Controller가 데이터 검증 및 Model에 데이터를 담는 역할 이외의 많은 일들을 처리하게 됨.
그래서 별도의 Sevice 계층을 만들어서 비즈니스 로직을 정의. Controller는 단순히 Service만 호출하면 되는 것!
스프링의 @Service Annotation을 생각해보시면 될 것 같습니다!
구조
동작 순서 & 동작 이유
DispatcherServlet
- Spring MVC의 핵심적인 기능.
기능이 복잡해질 수록 Controller에서 공통적으로 해야할 부분이 많아짐. 즉, 중복이 많아진다는 이야기!
Controller들의 공통 기능을 처리하기 위한 역할을 함.
입구 역할이라고 할 수 있음.
스프링 부트에서는 서블릿으로 자동으로 등록하면서 모든 경로에 대해서 매핑합니다.
1. 핸들러 조회 : 요청 URL에 매핑(ex) @RequestMapping)된 핸들러를 조회
Handler Mapping
- 핸들러 매핑에서 컨트롤러를 찾음
- 스프링 부트가 자동으로 등록하는 Handler Mapping 예시(우선순위가 존재)
- RequestMappingHandlerMapping : Annotation 기반의 컨트롤러인 @RequestMapping에서 사용
- BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러를 찾는다.
즉, 스프링부트는 가장 먼저 Annotation 기반의 컨트롤러를 찾고 컨트롤러가 존재하지 않으면 스프링 빈의 이름으로 찾고 우선순위대로 쭈욱 컨트롤러를 찾게 됩니다.
2. 핸들러 어댑터 조회 : 핸들러를 실행할 수 있는 핸들러 어댑터를 조회
3. 핸들러 어댑터 실행
Handler Adapter
- 컨트롤러도 다양한 방식이 있습니다. 어댑터 패턴을 사용해서 다양한 방식의 Controller를 처리할 수 있습니다.
- 핸들러 매핑을 통해서 찾은 핸들러를 실행.
- 또한, 스프링 부트가 자동으로 Handler Adapter를 등록합니다.(우선순위 존재)
- RequestMappingHandlerAdapter : 애노테이션 기반의 컨트롤러인 @RequestMapping에서 사용
- HttpRequestHandlerAdapter : HttpRequestHandler 처리
- SimpleControllerHandlerAdapter : Controller 인터페이스 처리
즉, 우선순위 대로 컨트롤러를 처리할 어댑터를 쭈욱 찾게 됩니다.
4. 핸들러 실행 : 핸들러 어댑터가 실제 핸들러 실행
5. ModelAndView 반환 : 모델과 뷰의 정보를 반환
6. ViewResolver 호출
ViewResolver
컨트롤러가 반환한 논리 뷰 이름을 실제 물리 뷰 경로로 변환하는 역할을 함!
7. View 반환
8. View 렌더링
이 글은 인프런 김영한님의 '스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술'을 수강하고 작성합니다.
출처:https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-mvc-1/dashboard