이 포스팅은 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술(김영한 님) 강의를 보고 정리한 것입니다.
모든것은 HTTP 기반으로 동작한다
클라이언트 <-> 서버는 모든것이 HTTP 기반으로 동작한다.
- html,text
- 이미지, 음성, 영상, 파일
- json, xml
- 서버간의 데이터 전송 등
웹서버 또한 HTTP기반으로 동작한다.
- 정적 리소스 제공(HTML, CSS, JS, IMAGE, 영상...), 기타 부가 기능들
- NGINX, APACHE
웹 애플리케이션 서버(WAS) 또한 HTTP 기반으로 동작한다.
- 동적 HTML, HTTP API(JSON)
- 서블렛, JSP, 스프링 MVC
- ex) 톰캣, JETTY, Undertow
웹서버와 웹애플리케이션 서버의 차이?
- 둘의 용어와 경계가 모호함
- 웹서버는 정적 리소스 제공, WAS는 애플리케이션 로직 수행에 특화되어 있음
- 웹서버도 프로그램을 실행하는 기능을 포함하기도 함
- WAS도 웹서버의 기능을 제공 함
- 자바는 서블릿 컨테이너의 기능을 제공하면 WAS로 여김
- 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음!
--> WAS는 애플리케이션 코드를 실행하는데 더 특화
웹 시스템의 구성은 WAS와 DB만으로 구성이 가능하다. but
- WAS, DB만으로 시스템이 구성 가능하다
- WAS는 정적 리소스, 애플리케이션 로직 모두 제공이 가능하기 때문이다.
이 구성만으로의 문제점으로는
- WAS가 너무 많은 역할을 담당하여 서버에 과부하가 우려되는 점
- 가장 비싼 애플리케이션 로직이 정적 리소스 때문에 수행이 어려울 수 있는 점
- WAS 장애시 오류 화면 노출이 불가능 한 점
해결 방법으로는
웹시스템 구성을 WAS, DB에서 WAS, DB + WEB 으로 바꾼다.
- 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽기 마련이다
- WAS, DB에서 장애가 일어날 경우 WEB서버가 오류 화면을 제공할 수 있다.
Servlet과 JSP를 이용한 동적 웹 개발 but
자바 서블릿은 웹서버의 성능을 향상하기 위해 사용되는 클래스의 일종이다.
클라이언트의 요청을 받아 그에 대한 결과를 반환해주는 역할을 한다.
내 개인적으로 JAVA + HTML 로 이해했다.
@WebServlet(name="responseHtmlServlet", urlPatterns = "/response-html")
public class ResponseHtmlServlet extends HttpServlet{
@Override
protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
resp.setContentType("text/html");
resp.setCharacterEncoding("utf-8");
PrintWriter writer = resp.getWriter();
writer.println("<html>");
writer.println("<body>");
writer.println("<div>안녕</div>");
writer.println("</body>");
writer.println("</html>");
}
}하지만 서블릿만을 이용한 개발에는 문제가 있었다.
위와 같이 많은 태그들을 직접 썻어야 했으며 이에 따른 html화면 렌더링은 큰 고통이였다.
이에 따라 JSP가 등장하게 된다.
Java 코드가 들어가 있는 HTML 코드라고 보면 된다.
그냥 서블릿이 JAVA + html 이였다면, 이건 HTML + JAVA 이다.
<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="/functions" prefix="f" %>
<html>
<head><title>Localized Dates</title></head>
<body bgcolor="white">
<jsp:useBean id="locales" scope="application"
class="mypkg.MyLocales"/>
<form name="localeForm" action="index.jsp" method="post">
<c:set var="selectedLocaleString" value="${param.locale}" />
<c:set var="selectedFlag"
value="${!empty selectedLocaleString}" />
<b>Locale:</b>
<select name=locale>
<c:forEach var="localeString" items="${locales.localeNames}" >
<c:choose>
<c:when test="${selectedFlag}">
<c:choose>
<c:when
test="${f:equals(selectedLocaleString, localeString)}" >
<option selected>${localeString}</option>
</c:when>
<c:otherwise>
<option>${localeString}</option>
</c:otherwise>
</c:choose>
</c:when>
<c:otherwise>
<option>${localeString}</option>
</c:otherwise>
</c:choose>
</c:forEach>
</select>
<input type="submit" name="Submit" value="Get Date">
</form>
<c:if test="${selectedFlag}" >
<jsp:setProperty name="locales"
property="selectedLocaleString"
value="${selectedLocaleString}" />
<jsp:useBean id="date" class="mypkg.MyDate"/>
<jsp:setProperty name="date" property="locale"
value="${locales.selectedLocale}"/>
<b>Date: </b>${date.date}</c:if>
</body>
</html>JSP를 이용한 개발에서는 JAVA 파일에서의 html태그와는 이별 할 수 있었지만 반면에 JSP파일 자체가 너무 커지는 부담이 있었다.
then, MVC
위에서 보았듯이 JSP만으로 비즈니스 로직과 뷰 렌더링을 처리한다면 너무 많은 역할을 하게 되고 결과적으로 유지보수가 어려워 진다.
- UI와 비즈니스 로직의 변경 주기가 다르다면 분리해야 한다
- 하지만 JSP는 자바코드와 UI를 한 파일에서 같이 쓰기에 하나의 유지보수 싸이클로 관리하기가 너무 어렵다.
- 서블릿은 자바코드를 실행하는데 최적화, JSP는 화면 렌더링에 최적화 되어 있어서 기능을 분리하는게 좋다.
따라서 나온 것이 모델, 뷰, 컨트롤러를 구분하자는 의미의 MVC 패턴이다.
M : Model, 뷰에 출력할 데이터를 담아둔다.
V : View, 모델에 담겨있는 데이터를 사용하여 HTML을 보여준다
C : Controller, HTTP요청을 받아 파라미터를 검증하고 비즈니스 로직을 실행하고 뷰에 전달할 데이터를 모델에 담는다.
장점
- 각각의 영역에서 관심사가 분리되어 있기에 개발자는 개발에 집중할 수 있다.
- 유지보수가 용이해진다.
--> 개발의 유연성 ++ , 애플리케이션의 확장성 ++
한계
- 모델과 뷰의 완전한 독립은 불가능하다.
- MVC의 크기가 커질수록 C-M-V의 라이프 사이클이 강하게 연결되는 바람에 분리/테스트가 어려워진다.
- 이 문제를 해결하기 위한 파생 패턴들이 존재한다( ex)MVP,MVVM... )
