[Spring MVC 1] 서블릿/JSP/MVC (2)

♪ 학습 내용 

MVC 패턴과 한계

---

* MVC 패턴

 

Model : 뷰에 출력할 데이터를 담는다. 따라서 뷰는 모델을 통하여 렌더링에만 집중

 

View : 모델에 담겨있는 데이터를 이용하여 화면에 렌더링 --> HTML 생성

 

Controller : HTTP 요청을 받아 비즈니스 로직 실행(서비스 계층 이용), 뷰에 전달할 데이터를 모델에 담는다

 

 

컨트롤러로 서블릿을, 뷰로 JSP를 사용했다!!

 

데이터를 담을 Model은 ?? 

 

request.setAttribute();

request.getAttribute();

HttpServletRequest 객체 내부에 데이터를 담음으로써 request 객체를 모델로 사용하였다.

 

대충 서블릿의 service에서 request에 데이터를 담고, JSP(뷰)에서 꺼내 사용!

 

 

RequestDispatcher dispatcher = request.getRequestDispatcher("경로");
dispatcher.forward(request, response);

forward --> 다른 서블릿이나 JSP로 이동

 

***WEB-INF 경로의 JSP는 외부에서 호출 불가하다.

url 경로를 입력해 직접 접근이 불가하고 서블릿을 통해 호출함으로써 접근 가능

! 항상 컨트롤러를 거치도록 설계 !

 

request 객체(모델)에 새로 저장한 멤버객체를 담아 JSP(뷰)로 이동

 

 

기존에는 위의 JSP 에서 모델의 데이터인 member를  꺼내려면 다음과 같이 접근해야한다.

<%= request.getAttribute("member") &>

 

하지만 JSP가 지원하는 다음 문법으로 더 쉽게 접근하였다.

 

EL (Expression Language)

//request의 attribute에 담긴 데이터에 편리하게 접근 가능

${member.id}

 

MVC 도입으로 컨트롤 로직과 뷰를 분리했다!

 

 

//jstl 사용 선언
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

//jstl을 이용한 forEach문 ( 자바의 forEach문을 사용한 것보다 깔끔하다 )
<c:forEach>

추가로 url에는 서블릿 경로 그대로이지만, forward 를 통해 화면은 뷰인 JSP인 것을 확인할 수 있었다

 

* MVC 패턴의 한계

 

앞서 MVC 패턴 공부하면서 느낀 점이 있다면 서블릿 만들때마다 계속 같은 코드를 반복했다는 것.

//계속 반복
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request,response);

외에도 공통되는 부분이 많은데 복잡해질 수록 공통 처리 부분은 더 많이 늘어날 것. 

 

공통 처리는 어렵다.

 

그렇기 때문에 프론트 컨트롤러(Front Controller) 패턴을 도입!!

 

그리고 이 프론트 컨트롤러는 곧 스프링 MVC의 핵심이기도 하다.

 

---

♪ 다음 학습 내용 

 

프론트 컨트롤러 패턴 도입

 

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - 인프런 | 강의