[6] 스프링 MVC (3) - 서블릿 / JSP / MVC 패턴
개요
Java 백엔드 웹 기술
의 역사
에 따라 순차적
으로 어떻게 발전
되어왔는지 비교할 예정
서블릿
--> JSP
--> MVC 패턴
--> 프론트 컨트롤러 패턴
--> 스프링 MVC
서블릿(Servlet)
[ 사용 ]
( MemberSaveServlet )
회원가입 Form 결과
에 대해 저장하는 Servlet
( MemberListServlet )
저장된 member들의 List
를 보여주는 HTML
[ 한계점 ]
Java 코드
로 HTML을 만드는 과정
이 매우 비효율적
--> 템플릿 엔진
이 등장한 이유!
(JSP
/ Thymeleaf
/ Freemarker
/ Velocity
등)
JSP(Java Server Pages)
[ 설명 ]
Java 언어
를 기반으로 하는 Server Side 스크립트 언어
HTML 코드
에 Java언어를 넣어
동적인 웹 페이지
를 생성
Java 코드
로 HTML을 비효율적으로 작성
하는 서블릿(Servlet)
의 단점을 개선
JSP
는 내부적으로 Servlet으로 변환
되어 실행
page import
: <%@ page import="hello.servlet.domain.member.MemberRepository" %>
Java 코드 삽입
: <% ~~ %>
Java 코드 출력
: <%= ~~ %>
[ 적용 ]
( save.jsp )
( members.jsp )
[ 한계 ]
비즈니스 로직
이 모두 JSP에 노출
JSP
가 비즈니스 로직
+ 뷰
의 역할을 모두 해야한다
--> 규모가 커질수록 관리하기가 힘들어짐
비즈니스 로직
과 뷰
가 한 곳
에 있다
--> 따로 관리
해야 한다!!
이러한 JSP의 한계
때문에 Model View Controller로 역할을 분리
한 MVC 패턴
이 등장한 것
MVC 패턴
[ 개요 ]
변경의 라이프 사이클
이 다르다
: UI를 수정하는 일
/ 비즈니스 로직을 수정하는 일
은 각각 다르게 발생할 가능성이 높고 서로 영향을 주지 X
따라서 변경의 라이프 사이클
이 다른데 하나의 코드로 관리
하는 것은 유지보수하기에 좋지 않다
기능 특화
: JSP같은 뷰 템플릿
은 화면을 렌더링 하는데 최적화
되어있기 때문에 해당 역할만 하는것이 가장 효과적
Model / View / Controller
로 역할 분리
Model
: View
에 출력할 데이터를 담아두는 역할
View
: Model
에 담겨있는 데이터를 통해 화면에 렌더링 하는 역할
Controller
: HTTP 요청 파라미터를 검증
/ 비즈니스 로직 수행
/ 결과 데이터를 Model에 담는다
Controller
에 비즈니스 로직
을 둘 수 있지만, 그렇게 되면 너무 많은 일을 담당
함
--> 그래서 일반적
으로 비즈니스 로직을 수행하는 서비스(Service)라는 계층을 별도
로 만든다
[ 적용 ]
MVC 패턴
Servlet
을 Controller
로 사용
JSP
를 View
로 사용
HttpServletRequest
를 Model
로 사용
/WEB-INF
: 해당 경로에 jsp 파일을 위치
시켜서 외부에서 접근 할 수 없게 처리
dispatcher
: 다른 Servlet
이나 JSP
로 이동
하는 기능
redirect
vs forward
redirect
: 실제 클라이언트(웹 브라우저)
에 응답이 나갔다가 redirect경로로 다시 요청
(url 경로 변경 O)
forward
: 서버 내부에서 호출해서 페이지를 이동
하는 것 (url 경로 변경 X)
( MvcMemberSaveServlet )
Model 역할
을 하는 HttpServletRequest 객체에 저장
--> 저장된 데이터
는 View에서 꺼내 쓸 수 있음
( MvcMemberListServlet )
[ 한계 ]
포워드(forward) 중복
: viewPath를 지정하고 이동시키는 과정
이 모든 Servlet에서 반복적
으로 일어난다
ViewPath 중복
: 모든 절대 경로를 입력
해야 하기 때문에 viewPath 입력시 중복
이 발생
prefix
: /WEB-INF/views/
suffix
: .jsp
- 사용하지 않는 코드
: HttpServletRequest
/ HttpServletResponse
객체를 사용하지 않음에도 파라미터로 받는 경우가 생김
- (정리) 공통처리 어려움
: 공통으로 중복되는 부분
을 하나로 처리하지 못해
전체적으로 중복
이 많이 발생함
위와 같은 문제점
들 때문에 공통 부분을 효율적으로 처리
하는 프론트 컨트롤러(Front Controller) 패턴이 필요
스프링 MVC의 내부 구조의 핵심
이 바로 프론트 컨트롤러(Front Controller) 패턴
이다
- 다음 글부터는
프론트 컨트롤러(Front Controller) 패턴을 직접 만들어 볼 것
이다