서버와 클라이언트
- 서버 : 특정한 서비스를 제공하는 컴퓨터
- 클라이언트 : 이러한 서비스를 이용하는 사용자
서블릿이란 무엇인가?
- 웹에서 동적인 페이지를 java로 구현한 서버 측 프로그램
JAVA언어를 이용하여 사용자의 요청을 받아 처리하고
그 결과를 다시 사용자에게 전송하는 역할의 Class파일
Context Path :
애플리케이션에 접근하는 경로(애플리케이션의 root경로)http://localhost:[port번호]/[프로젝트 별칭]/[servlet명] ex) http://localhost:9080/first/test1.do
사용자 데이터 전송방식 (post와 get의 차이)
- get
- URL창에 "?"뒤에 데이터를 입력하는 방법(쿼리스트링)
- 데이터가 여러 개일경우 &로 묶어서 보냄
- 데이터 검색에 많이 사용하고
데이터 크기에 한계가 있으며 보안이 취약하다.
(전송데이터가 노출된다)
- post
- BODY의 내용을 보내는 방식으로 데이터 크기에 제한이 없다
- 보안이 뛰어나다. (데이터 노출 X)
- 두 방식의 사용목적
GET은 서버의 리소스에서 데이터를 요청할 때,
POST는 서버의 리소스를 새로 생성하거나 업데이트할 때 사용한다.
DB로 따지면 GET은 SELECT 에 가깝고,
POST는 Create 에 가깝다고 보면 된다.- 요청메세지 BODY 유무 차이
GET 은 URL 파라미터에 요청하는 데이터를 담아 보내기 때문에 HTTP 메시지에 body가 없다. POST 는 body에 데이터를 담아 보내기 때문에 당연히 HTTP 메시지에 body가 존재한다.
스크립틀릿 표현식의 차이
- 일반 스크립틀릿 (Scriptlet)
<% %>
JSP페이지에서 JAVA언어를 사용하기 위한 요소 중
가장 많이 사용되는 요소- 선언 (Declaration)
<%! %>
JSP페이지 내에서 사용되는 변수 또는 메소드를 선언할 때 사용
선언된 변수 및 메소드는 전역의 의미로 사용된다.
일반 스크립틀릿과의 차이점은 일반 스크립틀릿에서 변수를 선언하면
지역변수로 선언된다.- 표현식 (Expression)
<%= %>
JSP페이지 내에서 사용되는 변수 또는 리턴값이 있는
메소드의 결과값을 출력하기 위해 사용.
결과값은 String 타입이며, 세미콜론 사용불가태그 | 표기법 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ Comments tag | <%-- 주석 --%> Directive tag | <%@ 지시자 %> Declaration tag | <%! 선언문 %> Scriptlet tag | <% 코드 %> Expression tag | <%= 표현식 %>
request | session 차이
- request
HttpServletRequest 객체 참조 변수
하나의 요청을 처리할 때 사용되는 영역- session
HttpSession 객체 참조 변수
하나의 브라우저와 관련된 영역
응답페이지에 전달할 값이 있을 경우
값을 어딘가에 보관해서 전달해야한다.
그 데이터를 담아놓을 내장객체 4가지 (Servlet scope)1. application
- application에 담은 데이터는 웹 애플리케이션 전역에서 꺼낼 수 있다.
2. session
- session에 담은 데이터는 모든 jsp와 servlet에서 꺼낼 수 있다.
- 한번 담아놓은 데이터는 내가 직접 지우기 전까지,
서버가 멈추기 전까지, 브라우저가 종료되기 전까지,
접근하여 사용할 수 있다.3. request
- request에 담은 데이터는 해당 request를 포워딩(forward)한
응답 jsp에서만 꺼낼 수 있다.4. page
- 해당 jsp 페이지에서만 꺼낼 수 있다.
위 객체들의 공통 메소드
- 데이터를 꺼내기 위한 메소드 getAttribute("키");
- 데이터를 넣기 위한 메소드 setAttrubute("키","벨류");
- 데이터를 지우기 위한 메소드 removeAttribute("키");
MVC 패턴의 의미
- Model
애플리케이션의 정보, 데이터를 나타낸다.
데이터베이스, 처음에 정의하는 상수, 초기화값, 변수 등을 뜻한다.
또한 이러한 DATA, 정보들의 가공을 책임지는 컴포넌트를 말한다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
- View나 Controller에 대해서 어떤 정보도 알지 못해야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.
- View
사용자 인터페이스 요소를 나타낸다.
(input 텍스트, 체크박스 항목 등)
데이터 및 객체의 입력, 그리고 보여주는 출력을 담당
데이터를 기반으로 사용자들이 볼 수 있는 화면이다.
- Model이 가지고 있는 정보를 따로 저장해서는 안된다.
- Model이나 컨트롤러와 같이 다른 구성요소들을 몰라야 한다.
- 변경이 일어나면 변경통지에 대한 처리방법을 구현해야만 한다.
- Controller
데이터와 사용자 인터페이스 요소들을 잇는 다리역할.
즉, 사용자가 데이터를 클릭하고 수정하는 것에 대한
'이벤트'를 처리하는 부분
- Model이나 View에 대해서 알고 있어야 한다.
- Model이나 View의 변경을 모니터링 해야 한다.
MVC 패턴을 사용해야 하는 이유
- 비즈니스 로직과 UI로직을 분리하여 유지보수를
독립적으로 수행가능- Model과 View가 다른 컴포넌트들에 종속되지 않아
애플리케이션의 확장성, 유연성에 유리함- 중복 코딩의 문제점 제거
parameter / attribute 차이
parameter
- 브라우저(client)에서 만들어진 정보
- 브라우저(사용자)에서 넘어온 값
- String만 사용가능
- request에만 저장이 가능
- HTML의 form 데이터 전송시 key/value 쌍으로 사용
attribute
- servlet(server)에서 만들어진 정보
- 개발자가 코딩으로 설정하는 값
- String외에 Object, Array 등 다양한 데이터 입력이 가능
- session, context 등에도 저장이 가능
- request 보다 좀 더 유연함
ServletRequest의 api를 확인해보면
우선, parameter에 관한 method를 찾아보면 알겠지만
setter는 없고 getter만 존재한다.
반면에, attribute는 setter, getter 둘 다 존재한다.
Api에서는 request parameter를 request와 함께 보내어지는
여분의 정보라고 한다.
또한 이 parameter들은 쿼리스트링이나 폼 데이터에
포함되어 있다고 한다.
즉, 우리가 servlet에서 사용하는 parameter들은
브라우저에서 사용자가 작성한 데이터들(ex, id, pwd 등)인 것이다.
그러므로 servlet에서는 parameter를 set할 수 없고 get만 가능하며,
getParameter()가 반환하는 값 또한 String이다
(우리가 입력하거나 입력된 값이므로).
반면 request attribute가 설정되는 방법에는
두 가지가 존재하는데,
하나는 servlet container가 request에 대한 정보를 이용할 수 있게 설정하는 것이고,
다른 방법은 setAttribute()를 이용해서 requestDispatcher가 호출되기 전에 request에 정보를 삽입할 수 있게 해주는 것이다.
그리고 getAttribute()의 반환값은 Object이다.
결론,
parameter는 브라우저(client)에서 만들어진 정보이고,
attribute는 servlet(server)에서 만들어진 정보이다.