인프런 커뮤니티 질문&답변
작성한 질문수
version 5. 어댑터 handle 메서드 인자 관련
작성
·
45
0
안녕하세요, 강의를 수강하고 있는 학생입니다.
이번 강의를 들으면서 궁금한 점이 생겨 글을 작성하게 되었습니다.
version 2에서 version 3로 넘어갈 때 해결한 문제 중 하나인 HttpServletRequest와 Response에 종속되어 있다와 관련하여 궁금한 점이 생겼습니다.
version 5에서 해당 핸들러(컨트롤러)에 맞는 어댑터를 찾아서 handle 메서드를 부를 때 인자로 핸들러를 제외하고도 HttpServletRequest 타입의 request, Response 타입의 response를 전달하는데, 그 이후에 딱히 이 두 인자에 종속될 필요가 없다고 느꼈습니다.
따라서, FrontController 서블릿에서 creatParamMap 메서드를 통해 파라미터를 담은 Map 타입 객체를 생성하여 인자로 전달하면 어떨까라는 생각이 들었습니다.
이러한 부분은 구현하는 사람의 재량인지, 제가 위에 설명한 방법에 문제가 있어서 그렇게 하지 않는 것인지 궁금합니다.
질문글 읽어주셔서 감사합니다.
답변 2
0
안녕하세요. 빵냥이님
생각하신 것 처럼 구현하셔도 괜찮습니다 🙂
여기서 핵심은 실제 사용자가 로직을 구현해야 하는 컨트롤러 인터페이스와 그 구현체들이 HttpServeltRequest에 종속적이지만 않으면 괜찮습니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
빵냥이님, 관련 질문 주셔서 감사합니다.
Spring MVC에서는 FrontController 패턴을 사용하여 하나의 서블릿이 HTTP 요청을 받은 후 해당 요청을 알맞은 컨트롤러에 전달하여 처리하게 합니다. 이 과정에서 HttpServletRequest와 HttpServletResponse를 전달하는 것은 Spring MVC의 설계 원칙에 부합합니다. 이는 컨트롤러에서 HTTP 요청에 관한 모든 정보(헤더 정보, 쿠키, 파라미터 등)에 접근하고 응답할 수 있도록 하기 위함입니다.
말씀하신대로 파라미터를 Map 타입으로 전달하는 것은 구현 가능하고 실제로 다양한 프레임워크나 라이브러리에서 이런 식으로 요청 데이터를 추상화하여 처리하기도 합니다. 하지만, 이 방법은 HttpServletRequest와 HttpServletResponse가 제공하는 다양한 기능과 데이터에 접근하는 유연성을 제한할 수 있습니다.
따라서, 질문하신 내용은 구현하는 개발자의 의도와 상황, 프로젝트의 필요성에 따라 결정될 수 있으나, Spring MVC의 설계 철학과 일관성을 유지하고자 기본적으로 HttpServletRequest와 HttpServletResponse를 사용하는 것을 선호합니다.
이러한 설계 결정은 어떤 방법이 절대적으로 옳다기보다는 각각의 접근 방식이 가진 장단점을 이해하고 상황에 맞게 선택하는 것이 중요합니다.
다시 한번 궁금한 점을 질문해 주셔서 감사합니다. 추가적인 질문이 있다면 언제든지 문의해 주세요.