목차
서블릿 VS JSP
서블릿의 불편함 : HTML 코드를 작성하려면 w.write("<html>")...처럼 메서드 안에 일일이 문자로 작성해주어야한다.
JSP의 불편함 : JSP파일 하나에 비즈니스로직, 화면표현 등의 너무 많은 역할이 주어진다. -> 나중에 유지보수가 어려워진다.
비즈니스 로직은 서블릿 처럼 다른곳에서 처리하고,
JSP는 목적에 맞게 HTML로 화면(View)을 그리는 일에 집중하도록 하자.
=> MVC 패턴 출현
MVC 패턴
이전의 문제점들
1. 1개의 JSP파일에 비즈니스로직, View 표현, DB연결.. 등 너무 많은 역할이 존재했다.
2. UI와 비즈니스로직의 연관성이 있을까?? 대부분의 경우는 서로 연관성도 없고
UI가 변경된다해서 비즈니스로직에 영향을 주는 경우도 없다. => 둘 사이에 변경 라이프 사이클이 다르다.
연관성이 없는 파트를 한 파일에서 관리해야하는 이유가 없다
Model View Controller (+Service)
위 문제점들을 해결하는 패턴이다.
| Model | 뷰에 출력할 데이터를 담는다. 뷰가 데이터를 모두 모델에 담아 전달하기때문에 뷰는 비즈니스로직이나 데이터 접근방식을 몰라도된다. 화면 렌더링에 집중할 수 있다. |
| View | 모델에 담겨있는 데이터를 사용해서 화면을 렌더링한다. |
| Controller | HTTP 요청을 받아 비즈니스 로직이 있는 서비스를 호출한다. 뷰에 전달할 결과데이터를 모델에 담는다. |
| +Service | 비즈니스로직이 담겨있다. |
MVC 패턴에서는 항상 Controller로 요청이 들어온 다음 뷰를 호출해야한다.
Dispatcher : 컨트롤러에서 뷰로 이동할 때 사용한다.
String viewPath = "/WEB-INF/views/save-result.jsp";
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);forward 메서드는 다른 서블릿이나 jsp로 이동할 수 있으며, 서버 내부에서 다시 호출이 발생한다.
(⚠ redirect는 클라이언트가 서버로 요청하면 서버가 클라이언트에게 응답해주고, 클라이언트는 서버로 다시 요청하된다. 총 2번 요청이 이루어진다.)
WEB-INF 폴더
WAS서버들의 규칙이다.
WEB-INF 폴더 안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없다.
= 무조건 controller를 거쳐서 요청이 들어와야만 WEB-INF 폴더 안의 JSP를 호출할 수 있다.
WEB-INF 폴더 밖의 JSP파일들은 주소창에 입력하면 바로 접속 가능하다.
request.setAttribute("키", 값), request.getAttribute("키");
Controller와 View는 데이터를 Mode로 전달한다.
Request객체는 내부에 데이터 저장소를 가지고 있는데 이것을 Model로 사용한다.
request.setAttribute("member", member)
//데이터 보관
request.getAttribute("member")
//데이터 조회 (object형식으로 반환한다)
JSP에서 getAttribute()메서드를 실행할때는 Object형식으로 반환하기때문에 형변환해주어야 한다.
너무 번거로우니 JSP의 ${ } 문법을 사용하자.
id = <% ((Member)request.getAttribute("member")).getId() %>
id = ${member.id}
MVC 패턴의 한계
1. 분홍색부분의 주소맵핑 코드 중복
"/servlet-mvc/members"
2. 초록색부분의 Dispatcher 코드 중복
RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);
3. 노란색부분의 viewPath 공통경로 중복
String viewPath = "/WEB-INF/views/save-result.jsp";
4. HttpServletRequest, HttpServletResponse 객체 미사용
=> 기능이 복잡해질수록 공통으로 처리해야하는 부분이 증가할 것이다.
공통기능을 메서드로 뽑아도 공통기능 메서드를 항상 호출해야하고, 실수로 호출하지 않으면 오류가 발생한다.
=> 컨트롤러 호출 전에 공통기능을 처리해주면된다. Front Controller 도입하자.
인프런 - 스프링MVC 백엔드 웹개발 핵심기술
'Backend' 카테고리의 다른 글
| 스프링 MVC 구조, DispatcherServlet, @RequestMapping.. (0) | 2021.12.01 |
|---|---|
| FrontController, View, Model, Adapter, Handler (0) | 2021.12.01 |
| 서블릿, HTTP Request, HTTP Response, ObjectMapper (0) | 2021.11.24 |
| 웹 애플리케이션의 이해 (0) | 2021.11.23 |
| SQL EXISTS, NOT EXISTS / IN, NOT IN (0) | 2021.11.15 |
