[스프링 웹 MVC 1편] 10. MVC 패턴 - 한계

지금까지 제작한 컨트롤러들의 코드를 보면 다음과 같이 중복되는 사항이 있다는 걸 발견할 수 있다.

 

1. viewPath의 중복

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

viewPath 변수 선언의 반복과 동시에 절대경로 표시에 필요한 다음 두 요소

prefix : /WEB-INF/views

postfix : .jsp

가 반복되는 것을 알 수 있다

 

2. 포워드 과정의 중복

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

서블릿에서 뷰로 이동하기 위한 포워드 과정이 각 서블릿 별로 반복해서 등장한다.

 

3. 사용하지 않는 코드의 중복

protected void service(HttpServletRequest request, HttpServletResponse response)

HttpServlet을 상속하는 과정에서 Override한 service 메서드의 response 객체는 현재 사용하지 않고 있고

때때로 다음 메서드에 전달된 인자를 사용하지 않는 경우도 존재한다. -> 불필요한 코드 발생 최적화 필요.

 

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

-> 왜? 

 

4. 공통처리가 어렵다

개발하는 경우 컨트롤러 단에서 로그 작성을 위한 기능을 탑재하고 싶은 경우가 있을 것이다.

로그는 모든 컨트롤러에서 동작해야하는 경우가 있을 것인데

현재 서블릿 MVC 개발 방식으로는 모든 컨트롤러에 동일한 코드를 여러번 넣어주어야한다.

 

해당 메서드를 항상 호출해야하는데, 모든 코드에 넣는 과정에서 누락이 발생하고 호출 해주는것 자체도 중복코드가 된다.

 

---

결론

공통처리가 어려운 문제를 해결하기 위해 프론트 컨트롤러 패턴이 도입된다.

Spring MVC의 핵심도 바로 이 프론트 컨트롤러에 있는데 지금부터 현재의 MVC 패턴을 차근차근 개선해 나가보겠다