DispatcherSevlet으로 전환

결론 및 요약

DispatcherServlet을 도입하여, 기존에 우리가 직접 작성했던 서블릿 코드와 맵핑 작업을 제거하고 스프링의 전통적인 서블릿 컨트롤러인 DispatcherServlet이 이를 대신 처리하도록 구현하였습니다. 이를 통해 Servlet Container-less 애플리케이션으로의 전환을 진행했습니다.

주요 내용 요약

1. 기존 서블릿의 복잡성 제거:

   • 이전에는 FrontController 서블릿을 직접 작성하여 모든 웹 요청을 처리하고, 매핑을 수동으로 설정했지만, 이번 시간에 DispatcherServlet을 사용함으로써, 이 복잡한 작업을 대신 처리하도록 하였습니다.
   • 이를 통해 서블릿을 다루는 복잡한 코드를 단순화할 수 있었습니다.

2. DispatcherServlet의 역할:

   • DispatcherServlet은 스프링의 핵심 서블릿으로, 맵핑, 요청 처리 및 핸들러 관리와 같은 중요한 역할을 수행합니다. 우리가 작성했던 프론트 컨트롤러가 수행하던 작업을 대신해줍니다.
   • Servlet은 이제 더 이상 직접 다루지 않고, DispatcherServlet이 이를 처리하게 됩니다. 이 서블릿은 들어오는 요청을 분석하여 적절한 컨트롤러로 디스패치합니다.

3. 맵핑 및 요청 전달:

   • URL 맵핑과 요청 파라미터 처리가 자동으로 이루어지도록 설계되었습니다. 스프링 컨테이너와 DispatcherServlet이 협력하여 요청을 적절한 핸들러로 전달하는 구조가 구현되었습니다.
   • 하지만, 404 에러가 발생한 이유는 DispatcherServlet에게 어떤 객체가 웹 요청을 처리할지 명시적으로 알려주지 않았기 때문입니다. 이는 추후 매핑 정보를 컨트롤러 클래스에 추가하는 방식으로 해결할 수 있습니다.

4. WebApplicationContext의 사용:

   • DispatcherServlet은 WebApplicationContext를 요구합니다. 이 컨텍스트는 일반적인 스프링 애플리케이션 컨텍스트보다 더 발전된 웹 전용 컨텍스트로, 웹 애플리케이션의 설정과 관련된 추가적인 기능을 제공합니다.
   • GenericWebApplicationContext를 사용하여 이 문제를 해결하였습니다.

결론:

DispatcherServlet을 도입하여 서블릿 관련 코드를 단순화하고, 웹 요청을 처리하는 과정을 더 유연하게 만들었습니다. 다음 시간에는 컨트롤러 클래스에 맵핑 정보를 추가하는 방법에 대해 학습하며, DispatcherServlet이 어떻게 더 효율적으로 작동하는지 살펴보게 될 것입니다.