MVC1 3rd Step

최보현·2022년 7월 26일

MVC Spring

MVC

목록 보기

3/18

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 - sec03
출처 : 스프링 MVC 1편

서블릿, JSP, MVC 패턴

싱글톤 패턴 적용

private static final MemberRepository instance = new MemberRepository();
public static MemberRepository getInstance() {
	return instance;
}

싱글톤 패턴을 적용했을 때, 그 싱글톤을 사용하기 위해서는 private MemberRepository memberRepository = MemberRepository.getInstance();을 사용해야한다.

멤버를 저장하는 서블릿

@WebServlet(name = "memberSaveServlet", urlPatterns = "/servlet/members/save")
public class MemberSaveServlet extends HttpServlet {
private MemberRepository memberRepository = MemberRepository.getInstance();
@Override
protected void service(HttpServletRequest request, HttpServletResponse
response)
throws ServletException, IOException {
System.out.println("MemberSaveServlet.service");
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));
Member member = new Member(username, age);
System.out.println("member = " + member);
memberRepository.save(member);

파라미터를 조회해서 Member객체를 만든다.
Member 객체를 MemberRepository를 통해서 저장한다.
Member 객체를 사용해서 결과 화면용 HTML을 동적으로 만들어서 응답한다.

멤버를 모두 조회하는 멤버 리스트 서블릿

memberRepository.findAll()1를 통해 모든 회원을 조회함

템플릿 엔진

HTML문서에 동적으로 변경해야 하는 부분만 자바 코드를 넣을 수 있도록 하는 것
ex) JSP, 타임리프, Freemarker, Velocity

JSP 사용 방법

JSP 라이브러리 추가

//build.gradle에 추가해줘야 함
//JSP 추가 시작
implementation 'org.apache.tomcat.embed:tomcat-embed-jasper'
implementation 'javax.servlet:jstl'
//JSP 추가 끝

JSP 파일 생성,<%@ page contentType="text/html;charset=UTF-8" language="java" %> 문구는 이것이 JSP 문서라는 것을 의미함

JSP는 서버 내부에서 서블릿으로 변환되는데, 만들었던 MemberFormServlet과 거의 비슷한 모습으로 변환됨 & 완전히 HTML과 동일함
request와 response가 사용가능 함
JSP는 자바 코드를 그대로 사용 가능함 ex)

<%@ page import="hello.servlet.domain.member.MemberRepository" %>
<%@ page import="hello.servlet.domain.member.Member" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%
// request, response 사용 가능
MemberRepository memberRepository = MemberRepository.getInstance();
System.out.println("save.jsp");
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));
Member member = new Member(username, age);
System.out.println("member = " + member);
memberRepository.save(member);
%>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
성공
<ul>
<li>id=<%=member.getId()%></li>
<li>username=<%=member.getUsername()%></li>
<li>age=<%=member.getAge()%></li>
</ul>
<a href="/index.html">메인</a>
</body>
</html>

- `<%@ page import="hello.servlet.domain.member.MemberRepository" %>`는 자바의 import문과 동일함
- `<% ~~ %>` 부분에는 자바 코드 입력 가능
- `<%= ~~ %>` 부분에는 자바 코드 출력 가능

서블릿과 JSP의 한계

좋은 점

서블릿으로만 개발할 때 뷰화면을 위한 HTML을 만드는 작업이 복잡했음
JSP 덕분에 뷰를 생성하는 HTML작업을 가져가고, 동적으로 변경이 필요한 부분만 자바 코드 적용함

문제점

JSP가 너무 많은 역할을 하게 된다
예를 들어, 회원 저장의 경우, 절반이 비즈니스 로직이고 나머지가 HTML로 보여주는 뷰 영역
JAVA코드, 데이터를 조회하는 리포지토리 등 다양한 코드가 모두 노출됨
유지보수 헬게이트 오픈

해결책

MVC 패턴
1. 비즈니스 로직은 서블릿처럼 다른 곳에서 처리
2. JSP는 자기 역할에 맞게 HTML로 뷰를 그리는 일에 집중

MVC패턴?

나타나게 된 계기

너무 많은 역할

하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을하게되고, 결과적으로 유지보수가 어려워짐

🌟변경의 라이프 사이클

JSP와 서블릿 사이에 변경의 라이프 사이클이 다름
예를 들어서 UI를 일부 수정하는 일과 비즈니스 로직을 수정하는 일은 각각 다르게 발생할 가능성이 매우 높고 대부분 서로에게 영향을 주지 않음 -> 변경의 라이프 사이클이 다른 부분을 하나의 코드로 관리하는 것은 유지보수하기 좋지 않음
~~(물론 UI가 많이 변하면 함께 변경될 가능성도 있다.)~~

기능 특화

특히 JSP 같은 뷰 템플릿은 화면을 렌더링 하는데 최적화 되어 있기 때문에 이 부분의 업무만 담당하는 것이 가장 효과적

그래서 MVC가 뭔데?

MVC 패턴이란, 하나의 서블릿이나, JSP로 처리하던 것을 컨트롤러(Controller)와
뷰(View) 라는 영역으로 서로 역할을 나눈 것

컨트롤러

HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행 & 뷰에 전달할 결과 데이터를 조회해서 모델에 담음

모델

뷰에 출력할 데이터를 담아둠. -> 뷰가 필요한 데이터를 모두 모델에 담아서 전달해주는 덕분에 뷰는 비즈니스 로직이나 데이터 접근을 몰라도 되고, 화면을 렌더링 하는 일에만 집중 가능

뷰

모델에 담겨있는 데이터를 사용해서 화면을 그리는 일에 집중 -> HTML을 생성하는 부분

컨트롤러에 비즈니스 로직을 두면 어때?
컨트롤러에 비즈니스 로직을 둘 수도 있지만, 이렇게 되면 컨트롤러가 너무 많은 역할을 담당하게 됨. 그래서 일반적으로 비즈니스 로직은 서비스(Service)라는 계층을 별도로 만들어서 처리함 그리고 컨트롤러는 비즈니스 로직이 있는 서비스를 호출하는 역할을 담당 -> 비즈니스 로직을 변경하면 비즈니스 로직을 호출하는 컨트롤러의 코드도 변경될 수 있음!

적용해보자!

request는 내부에 데이터 저장소를 가지고 있어서 request.setAttribute(), request.getAttribute()를 사용하여 데이터를 보관하고 조회 가능! -> 모델의 역할

컨트롤러 예시

@WebServlet(name = "mvcMemberFormServlet", urlPatterns = "/servlet-mvc/members/new-form")
public class MvcMemberFormServlet extends HttpServlet {
  @Override
  protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String viewPath = "/WEB-INF/views/new-form.jsp";
    RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
    dispatcher.forward(request, response);
  }
}

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

WEB-INF?
이 경로안에 JSP가 있으면 외부에서 직접 JSP를 호출할 수 없음 => 항상 컨트롤러를
통해서 JSP를 호출

redirect와 forward 그 차이는?

redirect, 실제 클라이언트(웹 브라우저)에 응답이 나갔다가, 클라이언트가 redirect 경로로 다시 요청 => 따라서 클라이언트가 인지할 수 있고, URL 경로도 실제로 변경됨

forward, 서버 내부에서 일어나는 호출이기 때문에 클라이언트가 전혀 인지하지 못함

뷰 예시

<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<html>
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<!-- 상대경로 사용, [현재 URL이 속한 계층 경로 + /save] -->
<form action="save" method="post">
username: <input type="text" name="username" />
age: <input type="text" name="age" />
<button type="submit">전송</button>
</form>
</body>
</html>

form의 action부분을 절대 경로가 아닌 상대 경로로 줌으로써 폼 전송시 현재 URL이 속한 계층 경로 + save가 호출됨
ex)
현재 계층 경로: /servlet-mvc/members/
결과: /servlet-mvc/members/save
JSP는 ${}문법을 제공하며 이를 통해 request의 attribute에 담긴 데이터를 편하게 조회 가능

//example
<li>id=${member.id}</li>
<li>username=${member.username}</li>
<li>age=${member.age}</li>

반복을 돌 수 있도록 만드는 JSP의 taglib기능
반복 <c:forEach> 기능을 사용하려면 다음과 같이 선언해야 함!
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%>
=> members 리스트에서 member 를 순서대로 꺼내서 item 변수에 담고, 출력하는 과정을 반복

MVC패턴의 한계점

포워드 중복

View로 이동하는 코드가 항상 중복 호출되어야 함 => 이를 메서드로 공통화해도 되지만, 해당 메서드도 항상 직접 호출함

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

ViewPath에 중복

jsp가 아닌 타임리프같이 다른 뷰로 변경한다면 전체 코드를 수정해야 함

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

사용하지 않는 코드

특히 response의 경우 현재 코드에서 사용되지 않음
+) HttpServletRequest와 HttpServletResponse를 사용하는 코드는 테스트 작성도 어려움...

HttpServletRequest request, HttpServletResponse response

공통 처리가 어려움

기능이 복잡해질 수 록 컨트롤러에서 공통으로 처리해야 하는 부분이 점점 더 많이 증가 => 공통 기능을 메서드로 뽑는다면? 결과적으로 해당 메서드를 항상 호출해야 하고, 실수로 호출하지 않으면 문제 발생 + 호출하는 것 자체도 중복

해결책

프론트 컨트롤러
컨트롤러 호출 전에 먼저 공통 기능을 처리해야 함 => 문지기 역할을 하는 기능이
필요 => 프론트 컨트롤러(Front Controller) 패턴을 도입하면 깔끔 해결 가능!

최보현

Novice Developer's Blog

이전 포스트

MVC1 2nd Step

다음 포스트