Spring MVC의 구조
우선 HTTP 요청이 오게되면 핸들러와 핸들러 어댑터를 통해서 컨트롤러를 호출한다.
스프링은 이미 필요한 핸들러 매핑과 핸들러 어댑터를 대부분 구현해 두었기 때문에 개발자가 직접 핸들러 매핑과 핸들러 어댑터를 만드는 일은 거의 없다.
1. DispatcherServlet이 핸들러를 조회해서 핸들러를 매핑한다.
HandlerMapping을 순서대로 실행해서 핸들러를 찾는다
2. 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터를 통해서 실제 컨트롤러를 호출한다.
디스패처서블릿이 조회한 핸들러 어댑터를 실행하면서 핸들러 정보도 같이 넘겨주고 그 결과를 반환한다.
애노테이션 기반의 컨트롤러, @RequestMapping 을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter(요청 매핑 핸들러 어댑터)가 이 부분에서 동작하게 된다.
@RequestMapping을 통해서 들어오는 수많은 다양한 파라미터들을 어떤 방식으로 처리해야 하는지 직적 신경쓸 필요가 없는데 그 이유는 Argument Resolver를 호출해서 컨트롤러가 필요로 하는 다양한 파라미터 값들을 생성해주기 때문이다.
이 파라미터의 값들이 모두 준비가 되면 컨트롤러를 호출하면서 값을 넘겨주게 된다.
Spring은 30개가 넘는 Argument Resolver를 기본으로 제공한다.
정리 : 우리가 뭘 하든 이미 준비되어 있으니 사용하기만 하면 된다.
Spring MVC의 구조
우선 HTTP 요청이 오게되면 핸들러와 핸들러 어댑터를 통해서 컨트롤러를 호출한다.
스프링은 이미 필요한 핸들러 매핑과 핸들러 어댑터를 대부분 구현해 두었기 때문에 개발자가 직접 핸들러 매핑과 핸들러 어댑터를 만드는 일은 거의 없다.
1. DispatcherServlet이 핸들러를 조회해서 핸들러를 매핑한다.
HandlerMapping을 순서대로 실행해서 핸들러를 찾는다
2. 핸들러를 처리할 수 있는 핸들러 어댑터를 조회한다.
3. 핸들러 어댑터를 통해서 실제 컨트롤러를 호출한다.
디스패처서블릿이 조회한 핸들러 어댑터를 실행하면서 핸들러 정보도 같이 넘겨주고 그 결과를 반환한다.
애노테이션 기반의 컨트롤러, @RequestMapping 을 처리하는 핸들러 어댑터인 RequestMappingHandlerAdapter(요청 매핑 핸들러 어댑터)가 이 부분에서 동작하게 된다.
@RequestMapping을 통해서 들어오는 수많은 다양한 파라미터들을 어떤 방식으로 처리해야 하는지 직적 신경쓸 필요가 없는데 그 이유는 Argument Resolver를 호출해서 컨트롤러가 필요로 하는 다양한 파라미터 값들을 생성해주기 때문이다.
이 파라미터의 값들이 모두 준비가 되면 컨트롤러를 호출하면서 값을 넘겨주게 된다.
Spring은 30개가 넘는 Argument Resolver를 기본으로 제공한다.
정리 : 우리가 뭘 하든 이미 준비되어 있으니 사용하기만 하면 된다.
