단계별 도입
v1
v2
- view 처리 객체 생성 : My view
- controller가 포워드 고민 x -> 단순히 My view만 생성해서 보내면 됨
My view : render(forward) 로직
v3
- 모델 개념 도입
- 컨트롤러가 서블릿 사용 x (따라서 setAttribute도)
- 컨트롤러는 전체 링크가 아닌 논리이름만 반환
/WEB-INF/views/new-form.jsp물리이름
new-form논리이름 - front controller에서 지저분한 것들 처리
v4
- 컨트롤러가 모델 객체 생성
- 기존 구조에서 모델을 파라미터로 넘기고, 컨트롤러는 뷰의 논리이름만 반환
v5
- 핸들러 어댑터 : 다양한 컨트롤러 호출
MVC 컨트롤러
- DispacherServlet : 부모 클래스에서 HTTPServlet을 상속, 서블릿으로 동작
@Component 를 호출하려면 두가지가 필요 (스프링이 대부분 구현)
- HandlerMapping(핸들러매핑) 핸들러 매핑으로 이 컨트롤러를 찾음
- HandlerAdapter(핸들러어댑터) 찾은 핸들러를 실행
스프링 부트가 자주 등록하는 핸들러매핑 / 핸들러어댑터 / 뷰 리졸버
순서 우선순위별
HandlerMapping
-
RequestMappingHandlerMapping : 애노테이션 기반 컨트롤러인 @RequestMapping 에서 사용
-
BeanNameUrlHandlerMapping : 스프링 빈의 이름으로 핸들러 찾음
HandlerAdapter
- RequestMappingHandlerAdapter : 애노테이션 기반
- HttpRequestHandlerAdapter : HttpRequestHandler 처리
- SimpleControllerHandlerAdapter : Controller 인터페이스 처리 (과거에 사용)
ViewResolver
- BeanNameViewResolver : 빈 이름으로 뷰를 찾아 반환
- InternalResourceViewResolver : JSP를 처리할 수 있는 뷰 반환
애노테이션 기반 @RequestMapping
- RequestMappingHandlerMapping
- RequestMappingHandlerAdapter
@Controller
스프링 빈으로 자동 등록 (내부에 @Component 애노테이션이 포함 -> 컴포넌트 스캔 대상)
@RequestMapping
요청 정보를 매핑
💡 RequestMapping / HandlerMapping은 @RequestMapping , @Controller가 클래스 레벨에 붙어 있는 경우 매핑 정보로 인식
또는
또는
+) 리턴 값이 String 일 때
@Controller는 뷰 이름으로 인식 -> 뷰를 찾고 랜더링
@RestController는 HTTP 메시지 바디에 그대로 입력
