MVC패턴 적용과 그 한계

김영한님의 인프런 강의와 PDF를 바탕으로 정리하였습니다.
https://www.inflearn.com/courses?s=%EA%B9%80%EC%98%81%ED%95%9C

 

 

 

컨트롤러는 서블릿

뷰는 jsp

모델은 HttpServletRequest객체의 request내부 저장소

이렇게 MVC패턴을 적용한 회원관리 어플리케이션을 만들어보겠습니다.

 

 

컨트롤러에서 request.getParameter(), request.setParameter() 를 사용하여 데이터를 받고, 전달합니다.

 

 

회원가입 폼으로 이동시켜주는 MvcMemberFormServlet

dispatcher.forward() : 다른 서블릿이나 JSP로 이동할 수 있는 기능입니다. 서버 내부에서 다시 호출이 발생합니다.

 

Redirect VS forward

( 서버 내부에서 다시 호출한다하여 redirect와 헷갈릴 수 있는데, redirect는 서버에서서 다시 클라이언트로 갔다가 서버로 옵니다.

즉 redirect: 클라이언트->서버->클라이언트->서버->클라이언트 순서입니다.)

 

참고:
/WEB-INF
이 경로안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없습니다. 우리가 기대하는 것은 항상 컨트롤러를 통해서 JSP를 호출하는 것입니다.
(webapp에 있으면 컨트롤러 안거치고 호출, WEB-INF에 있으면 컨트롤러 거치고 호출)

 

회원등록 폼 jsp(뷰)

 

상대경로 :

여기서 form의 action을 보면 절대 경로(로 시작)이 아니라 상대경로(로 시작X)하는 것을 확인할 수 있습니다. 이렇게 상대경로를 사용하면 폼 전송시 현재 URL이 속한 계층 경로 + save가 호출됩니다.
현재 계층 경로: /servlet-mvc/members/
결과: /servlet-mvc/members/save

 

 

다음은 회원저장 서블릿(컨트롤러) MvcMemberSaveServlet

HttpServletRequest를 Model로 사용
request가 제공하는 setAttribute() 를 사용하면 request 객체에 데이터를 보관해서 뷰에 전달할 수 있습니다.
뷰는 request.getAttribute() 를 사용해서 데이터를 꺼내면 됩니다.

 

 

 

회원 등록후 jsp(뷰)

<%= request.getAttribute("member")%> 로 모델에 저장한 member 객체를 꺼낼 수 있지만, 너무 복잡해진다.
JSP는 ${} 문법을 제공하는데, 이 문법을 사용하면 request의 attribute에 담긴 데이터를 편리하게 조회할 수 있습니다.

 

 

 

 

 

회원목록 조회 서블릿(컨트롤러) MvcMemberListServlet

회원 목록을 보여주는 jsp(뷰)

모델에 담아둔 members를 JSP가 제공하는 taglib기능을 사용해서 반복하면서 출력했습니다.

members 리스트에서 member를 순서대로 꺼내서 item 변수에 담고, 출력하는 과정을 반복합니다.

<c:forEach> 이 기능을 사용하려면 다음과 같이 선언해야 합니다.
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>

 

 

---

이전에 비해 많이 발전했지만 여전히 많은 한계점이 있습니다.

MVC 패턴 - 한계

MVC 패턴을 적용한 덕분에 컨트롤러의 역할과 뷰를 렌더링 하는 역할을 명확하게 구분할 수 있습니다.
특히 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적입니다. 단순하게 모델에서 필요한 데이터를 꺼내고, 화면을 만들면 됩니다.
그런데 컨트롤러는 딱 봐도 중복이 많고, 필요하지 않는 코드들도 많이 보입니다.

 

 

MVC 컨트롤러의 단점 :

 

1. 포워드 중복

View로 이동하는 코드가 항상 중복 호출되어야 합니다. 물론 이 부분을 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출해야 합니다.

 

2. viewPath에 중복

 

3. 사용하지 않는 코드

다음 코드를 사용할 때도 있고, 사용하지 않을 때도 있습니다. 특히 response는 현재 코드에서 사용되지 않습니다.

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

 

 

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

 

정리하면 공통 처리가 어렵다는 문제가 있다.
이 문제를 해결하려면 컨트롤러 호출 전에 먼저 공통 기능을 처리해야 합니다. 소위 수문장 역할을 하는 기능이 필요합니다. 프론트 컨트롤러(Front Controller) 패턴을 도입하면 이런 문제를 깔끔하게 해결할 수 있습니다. (입구를 하나로!)
스프링 MVC의 핵심도 바로 이 프론트 컨트롤러에 있습니다.