스프링 MVC 1 - JSP MVC 패턴의 한계

MVC 패턴 - 한계

https://5bong2-develop.tistory.com/292
위 링크 코드들을 보면 문제점이 많아 보인다.

문제점

포워드 중복

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

View로 이동하는 코드가 항상 중복 호출된다.
이 부분은 메서드로 공통화 할 수 있지만, 해당 메서드도 직접 호출해야 하는 단점이 있다.

ViewPath에 중복

String viewPath = "/WEB-INF/views/new-form.jsp";

• prefix : WEB-INF/views/
• suffix : .jsp
  만약 jsp가 아닌 thymeleaf나 다른 뷰 템플릿 엔진으로 변경하거나, 디렉토리를 바꾸면 전체 코드를 다 변경해야 하는 대참사가 일어난다.

사용하지 않는 코드

사용할 때도, 사용하지 않을 때도 있다.
HttpServletRequest request, HttpServletResponse response
특히 response는 현재 코드에서 사용되지 않는다.

그리고 HttpServletRequest, HttpServletResponse를 사용하는 코드는 테스트 케이스 작성도 어렵다.

공통 처리

기능이 복잡해지면 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가할 것이다.
단순하게 공통 메서드로 뽑으면 될 것 같지만, 결과적으로 해당 메서드를 항상 호출해야 하고 실수로 호출하지 않으면 문제가 된다.
그리고 호출하는 것 자체가 중복이다.

정리

정리하면 공통 처리가 어렵다는 문제다.
이 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리해야 한다.
이는 프론트 컨트롤러(Front Controller) 패턴을 도입하면 문제를 깔끔하게 해결할 수 있다.
프론트 컨트롤러는 가장 앞에서 무언가의 역할을 해준다.
스프링 MVC의 핵심도 바로 프론트 컨트롤러에 있다.

출처 : 인프런 김영한 지식 공유자님 강의 - 스프링 MVC 1편 백엔드 웹 개발 핵심 기술