MVC 프레임워크 만들기

byeol·2022년 12월 20일

스프링 웹 MVC 1

목록 보기

4/6

ppt로 정리하다보니 그림이 작으니 화면확대를 통해서 자세히 보기

앞서 배웠던 MVC 패턴의 한계점을 기억해보자
공통으로 처리해야 하는 부분이 있었다.

ViewPath의 prefix와 suffix 중복
RequestDispatcher의 중복
HttpServletResquest와 HttpServletResponse를 매개변수로 갖는 service()함수의 오버라이딩 -> HttpServlet은 HTTP호출과 응답으로 인해 테스트케이스르 만들기 어려움

이를 따로 빼서 만든다고 해도 결국 클래스의 메소드를 다시 호출해야 하므로 중복적으로 발생하는 것은 매한가지

따라서 등장한 것이 FrontController이다.

이번 시간에는 스프링 웹 MVC의 FrontController를 구현한 DispatcherServlet이 어떤 과정을 통해서 등장하게 되었는지 그걸 알아본다.

따라서 나는 각 버전마다 무엇인 개선되었는지 정리하도록 하겠다.

HTTP 요청은 무조건 처음에 FrontController로 간다.
그 이유는 여기서 WebServlet의 urlPatterns를 /front-controller/v1/*로 설정했기 때문이다.
ControllerV1이라는 인터페이스를 만든 이유는 프런트 컨트롤러가 이 인터페이스를 호출하도록 하는 것 즉 내부에 있는 3개의 컨트롤러 등록, 저장, 목록에 대한 구체적인 컨트롤러명 없이 인터페이스를 호출하는 것으로
유지보수를 간편하게 하는 것이다.
하지만 이 Version1의 문제점은 아직도 Dispatcher의 중복(빨간색 표시)

Version2에서는 RequestDispatcher의 중복을 피하기 위해서 MyView라는 클래스를 만들어서 따로 분리했다.
ControllerV2에서 눈여겨 봐야할 것은 process라는 메소드가 MyView를 return값으로 가지고 있다는 것 즉 FrontController에서 컨트롤러를 호출하고 이에 대한 반환값으로 MyView객체를 받을 것이며 이 객체를 통해서 render()함수를 호출하도록 바꾸었다.
MyView의 객체를 생성자를 통해서 viewPath라는 .jsp파일 경로를 받도록 설정해놓았다.
render라는 메소드는 HttpServlet을 상속받기 때문에 Http의 request와 response를 모두 받을 수 있다. 따라서 JSP로 forward가 가능하다.

Version2에서

Controller가 Http에 종속되지 않도록
즉 FrontController가 HttpServlet에 정보를 담아 주지 않고 Map을 만들어 그곳에 요청 파라미터 정보를 넣어 주기로 한다.
viewPath의 중복을 제거해보자
prefix인 /WEB-INF/views/와 suffix인 .jsp를 제거해보자

여기서 두개의 Map을 사용한다.
하나는 praramMap인데 Map<String,String>의 구조를 가지고 있으며
Http요청에 들어있는 data를 담는 그릇이다. 이제 우리는 Frontcontroller가 HttpServletRequest에 데이터를 담아 컨트롤러 보내는 것이 아니다.
이제는 저 paramMap이라는 그릇에 담아서 컨트롤레 보낼 것이다.
그 기능은 createParamMap이라는 메서드가 담당한다.
->따라서 이제 컨트롤러는 Http에 의존하지 않는다. 따라서 테스트코드를 만드는게 자유롭다

나머지 하나는 model인데 Map<String,Object>의 구조를 가지고 있으며 이는 서버 내부에 저장될 형태인 Object로 바꾸어진 데이터를 JSP에 보내기 위한 그릇으로 이용된다.

이 두개의 Map을 헷갈려하지 말자. 나는 헷갈려서 정리해둔다.
앞서 이야기 한 model이 HttpServlet의 request에 저장되지 않고 우리가 별도로 만들 ModelView의 model로 저장된다.
따라서 MyView에서 데이터를 JSP에 보내는 Dispatcher 과정에서 model로 받은 데이터를 request.setAttribute과정을 거치게 된다.