Servlet
Servlet Life-cycle
- main method 존재하지 않는다.
- 객체의 생성부터 사용의 주체가 사용자가 아닌 Servlet Container에게 있다.
Client가 요청을 하게 되면 servlet container는 serlvet객체를 생성(한번만) 하고, 초기화 (한번만)하며 요청에 대한 처리(요청시마다 반복)를 하게 된다. 또한 servlet 객체가 필요 없게 되면 제거하는 일까지 container가 담당하게 된다.
Servlet Life-cycle 주요 메서드
method | description |
init() | 서블릿이 메모리에 로드될 때 한번 호출 코드 수정으로 인해 다시 로드되면 다시 호출 |
doGet() | GET방식으로 data 전송시 호출 |
doPost() | POST방식으로 data 전송시 호출 |
service() | 모든 요청은 service()를 통해서 doXXX() 메소드로 이동 |
destroy() | 서블릿이 메모리에서 해제되면 호출 코드가 수정되면 호출 |
Parameter 전송 방식
GET | POST | |
특징 | 전송되는 데이터가 URL 뒤에 쿼리스트링으로 전달. 입력 값이 적은 경우나 데이터가 노출이 되도 문제가 없을 경우 사용 |
URL과 별도로 전송 HTTP haeder 뒤 body에 입력 스트림 데이터로 전달 |
장점 | 간단한 데이터를 빠르게 전송 form tag 뿐만 아니라 직접 URL에 입력하여 전송 가능 |
데이터의 제한이 없다. 최소한의 보안 유지 효과를 볼 수 있다. |
단점 | 데이터 양에 재한이 있다. (2kb) | 전달 데이터의 양이 같을 경우 get방식보다 느리다. |
JSP
자바 서버 페이지는 html 내에 자바 코드를 삽입하여 웹 서버에서 동적으로 웹 페이지를 생성하여 웹 브라우저에 돌려주는 언어이다. 자바 서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만 서블릿과는 달리 html 표준에 따라 작성되므로 웹 디자인하기에 편하다.
비슷한 구조로는 PHP, ASP, ASP.NET 등이 있다.
JSTL등의 JSP 태그 라이브러리를 사용하는 경우에는 자바 코딩없이 태그만으로 간략히 기술이 가능하므로 생산성을 높일 수 있다.
JSP 스크립팅 요소(Scripting Element)
1. 선언 ( declaration)
: 멤버변수 선언이나 메소드 선언하는 영역
<%! 멤버변수와 메소드 작성 %>
2. 스크립트릿 (scriptlet)
: Client 요청 시 매번 호출 영역으로 서블릿으로 변환시 service() method에 해당되는 영역
request, response에 관련된 코드 구현
<% java 코드 %>
3. 표현식 (Expression)
: 데이터를 브라우저에 출력할 때 사용
<%= 문자열 %>
주의 : ;(세미콜론) 사용하지 않음.
<%= 문자열 %> == <% out.print(문자열); %>
4. 주석 (comment)
: 코드 상에서 부가 설명을 작성
<%-- 주석 할 코드 --%>
주의 : <!-- html 주석 -->
JSP 지시자(Directive)
1. page Directive
: 컨테이너에게 현재 JSP 페이지를 어떻게 처리할 것인가에 대한 정보를 제공한다.
<%@ page attr1="val1" attr2="val2" .. %>
2. include Directive
: 특정 jsp file을 페이지에 포함
여러 jsp 페이지에서 반복적으로 사용되는 부분을 jsp file로 만든 후 반복 영역에 include 시켜 반복되는 코드를 줄일 수 있다.
<%@ include file = "dd.jsp" %>
3. taglib Directive
: JSTL 또는 사용자에 의해서 만든 커스텀 태그를 이용할 때 사용되며 JSP 페이지 내에 불필요한 자바 코드를 줄일 수 있다.
속성 | 기본값 | 설명 |
contentType | text/html; charset=ISO-8859-1 | 브라우저로 내보내는 내용의 MIME 형식 지정 및 문자 집합 지정 |
pageEncoding | ISO-8859-1 | 현재 JSP 페이지 문자집합 지정 |
import | 현재 JSP페이지에서 사용할 자바 패키지나 클래스를 지정 | |
session | true | 세션의 사용 유무 설정 |
errorPage | 에러가 발생할 때에 대신 처리될 JSP 페이지 지정 | |
isErrorPage | false | 현재 JSP페이지가 에러 핸들링 하는 페이지인지 지정하는 요소 |
JSP 기본 객체
기본 객체명 | 설명 |
request | html 폼 요소의 선택 값 등 사용자 입력 정보를 읽어올 때 사용 |
response | 사용자 요청에 대한 응답을 처리하기 위해 사용 |
pageContext | 각종 기본 객체를 얻거나 forward 및 include 기능을 활용할 때 사용 |
session | 클라이언트에 대한 세션 정보를 처리하기 위해 사용 page directive의 session 속성을 false로 하면 내장 객체는 생성이 안된다. |
application | 웹 서버의 애플리케이션 처리와 관련된 정보를 레퍼런스하기 위해 사용 |
out | 사용자에게 전달하기 위한 output 스트림을 처리할 때 사용 |
config | 현재 JSP 페이지에 대한 초기화 환경을 처리하기 위해 사용 |
page | 현재 JSP페이지에 대한 참조 변수에 해당됨 |
exception | error를 처리하는 JSP에서 isErrorPage 속성을 true 로 설정하면 excpetion내장 객체를 사용할 수 있고 기본은 false로 설정되어 있다. 전달된 오류 정보를 담고 있는 내장 객체 |
JSP 기본 객체의 영역(scope)
기본객체 | 설명 |
pageContext | 하나의 JSP 페이지를 처리할 때 사용되는 영역 한번의 클라이언트 요처에 대하여 하나의 JSP페이지가 호출되며, 이때 단 한 개의 page 객체만 대응이 된다. 페이지 영역에 저장한 값은 페이지를 벗어나면 사라진다. *커스텀 태그에서 새로운 변수를 추가할 때 사용한다. |
request | 하나의 HTTP 요청을 처리할 때 사용되는 영역 웹 브라우저가 요청을 할 때마다 새로운 request 객체가 생성됨 request 영역에 저장한 속성은 그 요청에 대한 응답이 완료되면 사라진다. |
session | 하나의 웹 브라우저와 관련된 영역 같은 웹브라우저 내에서 요청되는 페이지들은 같은 session들을 공유하게 됨. * 로그인 정보 등을 저장한다. |
application | 하나의 웹 어플리케이션과 관련된 영역 웹 어플리케이션당 1개의 application 객체가 생성됨 같은 웹 어플리케이션에서 요청되는 페이지들은 같은 application 객체를 공유함. |
JSP 기본객체의 영역(scope) - 공통 method
:servlet과 jsp 페이지 간에 특정 정보를 주고 받거나 공유하기 위한 메소드를 지원
method | 설명 |
void setAttribute(String name, Object value) | 문자열 name 이름으로 Object형 데이터를 저장한다. Object형이므로 어떠한 java 객체도 저장이 가능하다. |
Object getAttribute(String name) | 문자열 name에 해당하는 속성 값이 있다면 Object형태로 가져오고 없으면 null을 리턴한다. 따라서 리턴 값에 대한 적절한 형 변환이 필요하다. |
Enumeration getAttributeNames() | 현재 객체에 저장된 속성들의 이름들을 Enumeration 형태로 가져온다. |
void removeAttribute(String name) | 문자열 name 에 해당하는 속성을 삭제한다. |
WEB Page 이동
forward(request, response) | senRedirect(location) | |
사용 방법 | RequestDispatcher dispatcher = request.getRequest(path); dispatcher.forward(request, response); |
response.sendRedirect(location); |
이동 범위 | 동일 서버 (project)내 경로 | 동일 서버 포함 타 URL 가능 |
location bar | 기존 URL 유지 (실제 이동되는 주소 확인 불가) |
이동하는 page로 변경 |
객체 | 기존의 request와 response가 그대로 전달 | 기존의 request와 response는 소멸되고 새로운 request와 response가 생성 |
속도 | 비교적 빠름 | forward()에 비해 느림 |
데이터 유지 | request의 setAttribute(name. value)를 통해 전달 | request로는 data 저장 불가능 session이나 cookie를 이용 |
Session&Cookie
- http Protocol의 특징
: 클라이언트가 서버에 요청
서버는 요청에 대한 처리를 한 후 클라이언트에 응답
응답 후 연결을 해제 >> stateless
- 지속적인 연결로 인한 자원낭비를 줄이기 위해 연결을 해제한다.
- 그러나 클라이언트와 서버가 연결 상태를 유지해야 하는 경우 문제가 발생(로그인 정보 등)
- 즉 클라이언트 단위로 상태 정보를 유지해야 하는 경우 cookie와 session이 사용된다.
- http protocol의 특징을 보완하기 위해 사용
Cookie
- 서버에서 사용자의 컴퓨터(로컬)에 저장하는 정보 파일
- 사용자가 별도의 요청을 하지 않아도 브라우저는 request시 Request Header를 넣어 자동으로 서버에 전송
- key와 value로 구성되고 String 형태로 이루어져 있음
- Browser마다 저장되는 쿠키는 다르다. ( 서버에서는 Browser가 다르면 다른 사용자로 인식)
cookie의 사용 목적
- 세션 관리 : 사용자 아이디, 접속시간, 장바구니 등의 서버가 알아야 할 정보 저장.
- 개인화 : 사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다.
- 트래킹 : 사용자의 행동과 패턴을 분석하고 기록
cooki의 사용 예
- ID 자징 (자동 로그인)
- 일주일간 다시 보지 않기
- 최근 검색한 상품들을 광고에 추천
- 쇼핑몰 장바구니 기능
cookie의 구성 요소
- 이름 : 여러 개의 쿠키가 client의 컴퓨터에 저장되므로 각 쿠키를 구별하는 데 사용되는 이름
- 값 : 쿠키의 이름과 매핑되는 값
- 유효기간 : 쿠키의 유효기간
- 도메인 : 쿠키를 전송할 도메인
- 경로(path) : 쿠키를 전송할 요청 경로
cookie의 동작 순서
- 클라이언트가 페이지를 요청
- WAS는 cookie를 생성
- http header에 cookie를 넣어 응답
- browser는 넘겨받은 cookie를 pc에 저장하고 다시 WAS가 요청할 때 요청과 함께 cookie를 전송
- browser가 종료되어도 cookie의 만료 기간이 남아 있다면 클라이언트는 계속 보관
- 동일 사이트 재방문시 클라이언트의 pc에 해당 cookie가 있는 경우 요청 페이지와 함께 cookie를 전송
cookie의 특징
- 이름, 값, 만료일(저장기간 설정), 도메인, 경로 정보로 구성되어 있다.
- 클라이언트에 총 300개의 쿠키를 저장할 수 있다.
- 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
- 하나의 쿠키는 4kb까지 저장 가능하다.
session
- 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라 한다.
- WAS의 memory에 Object형태로 저장
- memory가 허용하는 용량까지 제한 없이 저장 가능
session의 사용 예
- stie내에서 화면을 이동해도 로그인(사용자 정보)이 풀리지 않고 유지
- 장바구니
session의 동작 순서
- 클라이언트가 페이지를 요청
- 서버는 접근한 클라이언트의 request-header 필드인 cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인
- session-id가 존재하지 않는다면 서버는 session-id를 쿠키를 사용해 서버에 저장. 쿠키 이름 :jssesionid
- 클라이언트는 재 접속시, 이 쿠키를 이용하여 session-id값을 서버에 전달
session의 특징
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장
- 웹 서버에 저장되는 쿠키
- 브라우저를 닫거나, 서버에서 세션을 삭제 했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.
- 저장 데이터에 제한이 없다.
- 각 클라이언트 고유 session id를 부여한다.
- session id로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공
session의 설정
- browser당 하나의 jsessionid를 할당 받음
- 아이디 또는 닉네임과 같이 로그인을 했을 경우 자주 사용하는 정보를 session에 저장하면 db를 접근할 필요가 없으므로 효율적이다.
Session과 Cookie 정리
Session | Cookie | |
Type | javax.servlet.http.HttpSession(Interface) | javax.servlet.http.Cookie(Class) |
저장 위치 | Server의 memory에 Object로 저장 | Client 컴퓨터에 file로 저장 |
저장 형식 | Object는 모두 가능(일반적으로 Dto, List 등 저장) | file에 저장되기 때문에 String 형태 |
사용 예 | 로그인 시 사용자 정보, 장바구니 등 | 최근 본 상품 목록, 아이디 저장(자동 로그인), 팝업 메뉴에서 '오늘은 그만보기' 등 |
용량 제한 | 제한 없음. | 도메인당 20개, 1쿠키 당 4kb |
만료 시점 | 알 수 없음.(클라이언트가 로그아웃하거나, 이정 시간동안 session 에 접근하지 않을 경우[만료 시간은 web.xml에 설정]) | 쿠키 저장시 설정( 설정이 없을 경우 browser 종료시 만료) |
공통 | 전역에 저장하기 때문에 project 내의 모든 JSP에서 사용 가능 MAP 형식으로 관리하기 때문에 key 값의 중복을 허용하지 않는다. |
EL (expression Language)
- EL은 표현을 위한 언어로 JSP 스크립트의 표현식을 대신하여 속성 값을 쉽게 출력하도록 고안된 language이다.
- 즉 표현식 <%= %>을 대체할 수 있다.
- EL 표현식에서 도트 연산자 왼쪽은 반드시 java.util.Map 객체 또는 java Bean 객체여야 한다.
- EL 표현식에서 도트 연산자 오른쪽은 반드시 맵의 키 이거나 Bean 프로퍼티여야 한다.
- EL에서 제공하는 기능
- JSP 네가지 기본 객체가 제공하는 영역의 속성 사용
- 자바 클래스 메소드 호출 기능
- 표현 언어만의 기본 객체 제공
- 수치, 관계, 논리 연산 제공
EL 문법 : [] 연산자
- EL 에는 Dot 표기법 외에 [] 연산자를 사용하여 객체의 값에 접근할 수 있다.
- [] 연산자 안의 값이 문자열인 경우, 이것은 맵의 키가 될 수도 있고, bean 프로퍼티나 리스트 및 배열의 인덱스가 될 수 있다.
- 배열과 리스트인 경우, 문자로 된 인덱스 값은 숫자로 변경하여 처리한다.
${ userinfo["name"] } or ${ userInfo.name }
${userName["1"]} or ${userName[1]} 둘다 가능
EL 내장 객체
category | identifier | type | description |
JSP | pageContext | Java Bean | 현재 페이지의 프로세싱과 상응하는 PageContext instance |
범위 (scope) |
pageScope | Map | page scoe에 저장된 객체를 추출 |
requestScope | Map | ||
sessionScope | Map | ||
applicationScope | Map |
EL 사용
- pageContext를 제외한 모든 EL 내장 객체는 Map이다.
- 그러므로 key 와 value 의 쌍으로 값을 저장하고 있다.
- ${ expr }
- null이더라도 null을 출력하지 않고 공백을 출력한다.
- ${ empty var}
- 값이 null이면 true
- 값이 빈 문자열
- 길이가 0인 배열
- 빈 Map객체는
- 빈 collection 객체이면
-> true
JSTL
- 자바 서버 페이지 표준 태그 라이브러리는 JAVA EE기반의 웹 애플리케이션 개발 플랫폼을 위한 컴포넌트 모음이다.
JSTL은 XML 데이터 처리와 조건문, 반복문, 국제화와 지역화 같은 일을 처리하기 위한 JSP 태그 라이브러리를 추가하여 JSP 사양을 확장했다.
JSTL
- custom tag : 개발자가 직접 태그를 작성할 수 있는 기능을 제공
- custom tag 중에서 많이 사용되는 것들을 모아서 JSTL이라는 규약을 만듦
- 논리적인 판단, 반복문의 처리, 데이터베이스 등의 처리를 할 수 있다.
- JSTL은 JSP 페이지에서 스크립트릿을 사용하지 않고 액션을 통해 간단하게 처리할 수 있는 방법을 제공
- JSTL에는 다양한 액션이 있으며 EL과 함께 사용하여 코드를 간결하게 작성할 수 있다.
JSTL Tag
- directive 선언 형식 : <%@ taglib prefix="c" uri="uri" %>
library | prefix | function | uri |
core | c | 변수 지원, 흐름 제어, url처리 |
변수 선언:<c:set>
- <c:set> 액션은 변수나 특정 객체의 프로퍼티에 값을 할당할 때 사용
- value 속성의 값이나 액션의 body content로 값을 설정
- var 속성은 변수를 나타내며 변수의 생존범위는 scope 속성으로 설정 ( 디폴트는 page)
- 특정 객체의 프로퍼티에 값을 할당할 때는 target속성에 객체를 설정하고 property에 프로퍼티명을 설정
예외
<c:catch>
- 기본적으로 JSP페이지는 예외가 발생하면 지정된 오류페이지를 통해 처리한다.
- <c:catch> 액션은 JSP페이지에서 예외가 발생할 만한 코드를 오류페이지로 넘기지 않고 직접 처리할 때 사용
- var 속성에는 발생한 예외를 담을 page 생존범위 변수를 지정
- <c:catch>와 <c:if> 액션을 함께 사용하여 java 코드의 try~catch 와 같은 기능을 구현할 수 있다.
조건문
<c:if> <c:choose> <c:when> <c:otherwise>
- <c:if> 액션은 test 속성에 지정된 표현식을 평가하여 결과가 true인 경우 액션의 body 컨텐츠를 수행
- <c:if> 액션의 var속성은 표현식의 평가 결과인 Boolean 값을 담을 변수를 나타내며 변수의 생존 범위는 scope 속성으로 설정
- <c:choose> <c:when> <c:otherwise> 액션을 사용하면 if, else if, else와 같이 처리할 수 있다.
반복문
<c:forEach>
- <c:forEach> 액션은 컬렉션에 있는 항목들에 대하여 액션의 Body 컨텐츠를 반복하여 수행
- 컬렉션에는 Array, Collection, Map 또는 콤마로 분리된 문자열이 올 수 있다.
- var 속성에는 반복에 대한 현재 항목을 담는 변수를 지정하고 items 속성은 반복할 항목들을 갖는 컬렉션을 지정
- varStatus 속성에 지정한 변수를 통해 현재 반복의 상태를 알 수 있다. (인덱스)
MVC Pattern (Model View Controller)
Web Application Architecture
- JSP를 이용하여 구성할 수 있는 Web Application Architecture는 크게 model1과 model2로 나뉜다.
- JSP가 클라이언트의 요청에 대한 Logic처리와 response page(view)에 대한 처리를 모두 하느냐, 아니면 response page(view)에 대한 처리만 하는지가 가장 큰 차이점이다.
- model2구조는 MVC 패턴을 web 개발에 도입한 구조를 말한다.
Model1 구조
- model1은 view와 logic을 JSP 페이지 하나에서 처리하는 구조를 말한다.
- client로부터 요청이 들어오게 되면 JSP 페이지는 java beand나 별도의 service class를 이용하여 작업을 처리, 결과를 client에 출력한다.
Model1 구조의 장단점
- 간단한 page를 구성하기 위해 과거에 가장 많이 사용되었던 architecture
장점 | 단점 |
구조가 단순하며 직관적이기 때문에 배우기 쉽다. | 출력을 위한 view(html) 코드와 로직 처리를 위한 java코드가 섞여 있기 때문에 jsp 코드 자체가 복잡해진다. |
개발 시간이 비교적 짧기 때문에 개발 비용이 감소한다. | JSP 코드에 Bavk-end(developer)와 front-end(designer)가 혼재되기 때문에 분업이 힘들어진다. |
project의 규모가 커지게 되면 코드가 복잡해지므로 유지보수 하기가 어려워진다. | |
확장성이 나쁘다 |
Model2의 구조
- model2는 모든 처리를 JSP 페이지에서 하는 것이 아니라 client 요청에 대한 처리는 servlet이, logic 처리는 java class(service, dao, ..), client에게 출력하는 response page를 JSP가 담당한다.
- model2 구조는 MVC pattern을 웹개발에 도입한 구조이며 완전히 같은 형태를 보인다.
Model2 | MVC Pattern | 설명 |
Service, DAO or Java Beans | Model | Logic(Business & DB Logic)을 처리하는 모든 것. controller로 부터 넘어온 data를 이용하여 이를 수행하고 그에 대한 결과를 다시 controller에 return한다. |
JSP | View | 모든 화면 처리를 담당. client의 요청에 대한 결과 뿐 아니라 controller에 요청을 보내는 화면단도 jsp에서 처리한다. logic 처리를 위한 java code는 사라지고 결과 출력을 위한 code만 존대 |
Servlet | Controller | client의 요청을 분석하여 logic 처리를 위한 model단을 호출한다. return 받은 결과 data를 필요에 따라 request, session에 저장하고, redirect 또는 forward 방식으로 jsp(view) page를 이용하여 출력한다. |
Model2 구조의 장단점
- Model2는 model1의 단점을 보완하기 위해 만들어졌으나, 다루기 어렵다는 단점이 있다.
장점 | 단점 |
출력을 위한 view(html) 코드와 로직 처리를 위한 java 코드가 분리 되었기 때문에 JSP는 model1에 비해 코드가 복잡하지 않다. | 구조가 복잡하여 초기 진입이 어렵다. |
화면단과 LOgic단이 분리 되었기에 분업이 용이해졌다. | 개발 시간의 증가로 개발 비용 증가 |
기능에 따라 code가 분리되었기 때문에 유지보수가 쉬워졌다. | |
확장성이 뛰어나다. |
'Spring' 카테고리의 다른 글
Spring WEB MVC (0) | 2021.10.31 |
---|---|
Spring Framework (0) | 2021.10.31 |
@annotation 정리 (0) | 2021.04.29 |
JPA Repository method 정리 (0) | 2021.04.29 |
Annotation 정리 (0) | 2021.04.25 |