JSP Servlet 복습 3

🎉 DispatcherServlet 기반 MVC 구조 최종 요약 🎉

DispatcherServlet 기반의 MVC 구조는 웹 애플리케이션의 요청 처리 흐름을 중앙 집중식으로 관리하고, 역할 분담을 통해 개발 효율성과 유지보수성을 높이는 디자인 패턴이야. 핵심 구성 요소와 흐름은 다음과 같아.

1. 클라이언트 요청 (View → DispatcherServlet): 사용자가 웹 브라우저를 통해 특정 URL을 요청하거나 액션을 수행하면, 이 요청은 웹 서버를 거쳐 DispatcherServlet에게 전달돼. @WebServlet("/") 또는 특정 패턴으로 매핑되어 모든 요청을 Front Controller로서 처리하는 역할을 해.

2. Handler Mapping (DispatcherServlet → Handler): DispatcherServlet은 받은 요청의 URL이나 다른 정보를 기반으로, 이 요청을 처리할 Handler (일반적으로 Controller)를 찾아. 이 과정은 설정 파일 (actionMapping.properties, XML 설정, 어노테이션 등)에 정의된 매핑 정보를 활용해 이루어져. (이전 강의 노트에서 HandlerMappingListener가 미리 준비해둔 map을 사용하는 방식이 바로 이 역할의 한 예시야!)

3. Controller 실행 (DispatcherServlet → Controller): DispatcherServlet은 Handler Mapping을 통해 찾은 Controller의 특정 메서드를 실행하면서, 클라이언트의 요청 정보 (HttpServletRequest)와 응답 정보 (HttpServletResponse)를 함께 전달해.

4. 비즈니스 로직 처리 (Controller → Service → Model): Controller는 전달받은 요청 정보를 바탕으로 필요한 Model 데이터를 얻기 위해 Service 계층을 호출하여 비즈니스 로직을 처리해. Service는 DAO (Data Access Object)를 통해 데이터베이스와 상호작용하기도 해.

5. ModelAndView 반환 (Controller → DispatcherServlet): Controller는 비즈니스 로직 처리 결과인 Model 데이터와 사용자에게 보여줄 View의 이름을 함께 담은 ModelAndView 객체를 DispatcherServlet에게 반환해.

6. View Resolver (DispatcherServlet → View): DispatcherServlet은 ModelAndView로부터 받은 View 이름을 기반으로 실제 View 객체 (JSP, Thymeleaf 등)를 찾아. View Resolver는 설정된 규칙에 따라 View 이름에 접두사, 접미사를 붙여 실제 파일 경로를 결정하는 역할을 해.

7. View 렌더링 (DispatcherServlet → View → Client): DispatcherServlet은 찾은 View에게 Model 데이터를 전달하고, View는 이 데이터를 이용하여 사용자에게 보여줄 최종적인 응답 (HTML, JSON 등)을 생성하고 웹 브라우저로 응답을 전송해.

🎨 DispatcherServlet의 좀 더 깊은 기능들 (내가 아는 선에서!) 🎨

실제 DispatcherServlet은 단순히 요청을 받고 Controller를 실행하는 것 외에도 다양한 강력한 기능들을 제공해서 웹 애플리케이션 개발을 훨씬 편리하고 효율적으로 만들어 줘. 몇 가지 주요 기능들을 알려줄게.

• Handler Interceptor: 요청 처리 전후에 특정 작업을 수행할 수 있도록 해주는 기능이야. 마치 요청이 Controller에 도착하기 전이나 Controller가 응답을 보내기 전에 "가로채서" 공통적인 로깅, 인증, 권한 검사 등의 작업을 처리할 수 있지. 여러 개의 Interceptor를 등록해서 순서대로 실행할 수도 있어.

• Exception Resolver: 애플리케이션 실행 중에 발생하는 예외를 중앙 집중적으로 처리할 수 있도록 해주는 기능이야. Controller나 Service 계층에서 예외가 발생하면 DispatcherServlet은 등록된 Exception Resolver들에게 이 예외를 처리할 수 있는지 물어보고, 처리 가능한 Resolver가 있으면 해당 Resolver에게 예외 처리를 맡겨. 이를 통해 에러 페이지를 보여주거나, API 응답을 일관된 형식으로 반환하는 등의 작업을 할 수 있어.

• Locale Resolver & Theme Resolver: 다국어 지원이나 웹 페이지의 테마를 일관성 있게 적용하는 데 도움을 주는 기능이야. Locale Resolver는 클라이언트의 요청 헤더 등을 분석해서 사용자의 언어 설정을 파악하고, Theme Resolver는 설정된 테마 정보를 제공해서 View에서 일관된 디자인을 적용할 수 있도록 도와줘.

• Multipart Resolver: 파일 업로드와 관련된 요청을 처리하는 데 필요한 기능이야. 클라이언트가 폼을 통해 파일을 업로드하면, Multipart Resolver가 이 요청을 분석해서 파일 데이터와 일반 폼 데이터를 분리하고, Controller에서 쉽게 사용할 수 있도록 변환해 줘.

• Data Binding & Validation: 클라이언트로부터 전송된 파라미터들을 Controller의 메서드 파라미터나 객체에 자동으로 바인딩(매핑)해주는 기능이야. 또한, 바인딩된 데이터의 유효성을 검증하는 기능도 제공해서, 사용자의 입력 오류를 쉽게 처리할 수 있도록 도와줘. @RequestParam, @ModelAttribute 등의 어노테이션이 이 기능을 사용할 때 활용돼.

• Flash Attributes: Redirect 시 데이터를 유지하는 데 사용되는 기능이야. Redirect를 하면 일반적으로 요청 스코프의 데이터는 사라지는데, Flash Attribute를 사용하면 Redirect 직전의 데이터를 다음 요청까지 유지할 수 있어서, 일회성 메시지 (성공/실패 메시지 등)를 전달하는 데 유용해.

이 외에도 DispatcherServlet은 다양한 확장 포인트를 제공해서 개발자가 필요한 기능을 추가하거나 기존 기능을 커스터마이징할 수 있도록 지원해. Spring MVC와 같은 프레임워크는 이러한 DispatcherServlet의 기능을 기반으로 더 편리하고 강력한 웹 개발 환경을 제공하는 거지.

---

1. ServletContextListener 구현체 (HandlerMapping 역할):

• HandlerMappingListener 클래스: ServletContextListener 인터페이스를 구현하고 있는 이 클래스는 서블릿 컨테이너 (Tomcat 같은 웹 서버)가 시작될 때 (contextInitialized 메서드)와 종료될 때 (contextDestroyed 메서드) 특정 작업을 수행할 수 있도록 해줘.
• 서버 시작 시 Controller 초기화: contextInitialized 메서드 안을 보면 주석으로 "//필요한 XxxController를 미리 생성한다."라고 되어 있고, 그 아래 actionMapping.properties 파일에서 정보를 읽어와서 Controller들을 미리 생성하고 Map<String, Controller>에 저장하는 로직이 담겨 있을 것으로 추측돼.
  • actionMapping.properties 파일에는 요청 키 (key)와 그 키에 해당하는 Controller 클래스 이름 (value)이 쌍으로 정의되어 있을 거야. 예를 들어, "select=SelectionController", "insert=InsertController" 처럼 말이지.
  • Properties 파일을 읽어서 각 키-값 쌍을 분리하고, Reflection이라는 Java 기능을 이용해서 문자열로 된 클래스 이름을 가지고 실제 Controller 객체를 생성하는 거야. (이미지에 (String--->객체생성=reflection개념) 이라고 친절하게 적혀 있네!)
  • 생성된 Controller 객체는 Map<String, Controller>인 map에 키와 값으로 저장돼. 여기서 키는 actionMapping.properties에 정의된 요청 키가 되고, 값은 생성된 Controller 객체가 되는 거지.
• map을 Application 영역에 저장: 마지막으로 application.setAttribute("map", map); 코드를 통해서 생성된 map 객체를 ServletContext (Application 영역)에 저장해. 이렇게 하면 DispatcherServlet을 포함한 웹 애플리케이션의 모든 서블릿과 JSP에서 이 map에 접근해서 필요한 Controller를 꺼내 쓸 수 있게 되는 거야.

핵심: 이 HandlerMappingListener는 요청 키와 실제 Controller 객체를 미리 연결해두는 역할을 해. 마치 전화번호부처럼, 특정 요청 키를 입력하면 어떤 Controller가 처리해야 하는지 바로 찾을 수 있도록 준비해두는 거지.

2. DispatcherServlet 클래스:

• @WebServlet("/front"): 이 어노테이션은 /front로 시작하는 모든 클라이언트 요청을 이 DispatcherServlet이 받아서 처리하도록 설정하는 거야. 앞서 설명했던 Front Controller 패턴의 핵심 역할을 하는 거지.
• Map<String, Controller> map = null;: DispatcherServlet 내부에 Controller들을 저장할 map 변수를 선언하고 초기화해.
• init(ServletConfig config) 메서드: 서블릿이 처음 생성될 때 딱 한 번 호출되는 메서드야.
  • map = (Map<String, Controller>) application.getAttribute("map"); 코드를 통해서 HandlerMappingListener가 Application 영역에 저장해둔 map 객체를 가져와서 DispatcherServlet의 map 변수에 할당해. 이제 DispatcherServlet은 어떤 요청 키에 어떤 Controller가 연결되어 있는지 알 수 있게 된 거야.
• service(HttpServletRequest request, HttpServletResponse response) 메서드: 클라이언트로부터 실제 요청이 들어올 때마다 호출되는 메서드야. 요청을 처리하는 핵심 로직이 여기에 담겨 있어.
  • request.getParameter("key"); 코드를 이용해서 클라이언트가 보낸 요청 파라미터 중에서 "key"라는 이름을 가진 값을 읽어와. 이 값이 바로 actionMapping.properties에 정의된 요청 키가 되는 거야. 예를 들어, 사용자가 "검색" 버튼을 눌렀다면 "select"라는 값이 넘어올 수 있겠지.
  • Controller con = map.get(key); 코드를 이용해서 DispatcherServlet이 가지고 있는 map에서 읽어온 요청 키에 해당하는 Controller 객체를 찾아. 전화번호부에서 이름을 찾아서 실제 전화번호를 얻는 것과 비슷해.
  • ModelAndView andView = con.handleRequest(); (이미지 1) 또는 ModelAndView andView = con.process(request, response); (이미지 2) 코드를 통해서 찾은 Controller 객체의 특정 메서드 (handleRequest 또는 process)를 호출해서 실제 요청 처리를 위임해. 이때 HttpServletRequest와 HttpServletResponse 객체를 함께 넘겨줘서 Controller가 클라이언트의 요청 정보를 활용하고 응답을 만들 수 있도록 하는 거야. 이 메서드는 처리 결과와 보여줄 View 정보를 담은 ModelAndView 객체를 반환할 것으로 예상돼.

핵심: DispatcherServlet은 클라이언트의 요청을 받으면 요청 키를 분석해서 미리 준비된 map에서 해당 요청을 처리할 Controller를 찾고, 그 Controller에게 실제 작업을 맡기는 역할을 해.

이미지 1과 2의 차이점:

두 이미지의 DispatcherServlet 코드를 보면 Controller의 메서드 이름이 약간 다른 것을 확인할 수 있어. 이미지 1에서는 con.handleRequest() 라고 되어 있고, 이미지 2에서는 con.process(request, response) 라고 되어 있지. 이는 강의 내용이 업데이트되거나 다른 패턴을 설명하기 위한 차이일 수 있어. 중요한 건 DispatcherServlet이 요청에 맞는 Controller를 찾아서 특정 메서드를 호출하여 실제 처리를 담당하게 한다는 점은 동일해.

결론적으로, 이 강의 노트는 DispatcherServlet 기반 MVC 프레임워크의 핵심적인 동작 방식을 아주 잘 보여주고 있어.

1. 서버 시작 시 (HandlerMappingListener): 요청 키와 Controller 객체를 미리 매핑해서 Application 영역에 저장해 둔다.
2. 요청 처리 시 (DispatcherServlet): 클라이언트로부터 요청을 받으면 요청 키를 이용해서 미리 매핑해둔 Controller를 찾아서 실제 처리를 위임하고, 그 결과를 받아서 응답을 생성한다.

이 과정을 통해 모든 클라이언트 요청을 중앙에서 효율적으로 관리하고, 각 요청에 맞는 Controller에게 책임을 분담하는 깔끔한 구조를 만들 수 있는 거야.