개요
왜 VO를 사용하는가?
-
데이터에 대한 의미 전달이 잘 되지 않기 때문에, 이 코드를 작성한 개발자만 알 수 있는 것
-
도저희 의미를 파악할 수 없음 => 가독성이 떨어짐
boardDAO.insertBoard("내용", "제목", "작성자");
public void insertBoard(String title, String writer, String content); // 이렇게 쓴다고?-
사실은 매개변수가 3개밖에 없어 상관이 없다고 생각할 수 있지
-
만약, 회원가입/쇼핑/주문 등 ==> 매개변수가 너무 많다면?
- 개수, 타입, 데이터의 순서까지 외워서 호출해야 하는 문제가 생김
VO(Value Object) 클래스
-
메소드의 매개변수나 리턴 데이터를 하나의 객체로 통합하는 클래스
-
테이블의 컬럼 이름에 해당하는 멤버변수를 작성한다.
public class BoardVO {
private int seq;
private String title;
private String writer;
private String content;
private Date regDate;
private int cnt;
}-
Alt + SHIFT + S=>Generate Getters and Setters항목 선택 -
데이터가 코드 상에서 명확하게 의미가 전달된다는 것!
-
사람들은 가독성이 좋아지고 유지보수가 편한 것을 선호합니다.- 그러다보니, 코드가 복잡해질 수 있는 가능성이 있습니다.
Client 개념
-
이 개념은 매우 상대적 => 사용해주는 것이 Client가 되는 것
-
DAO 입장에서는 나를 사용해주는 친구가 되지만,
-
어떤 클라이언트는 제목, 작성자, 내용까지만 보고 싶고
-
어떤 클라이언트는 다 필요없고, 데이터가 총 몇 번이 들어가 있는지만 알고 싶어
-
-
이렇게 다양한 요구사항을 만족하려면???
getBoardList1,2,3....?의 방식 -
비슷한 메소드를 여러 생성할 수 있는 방식은 이상함
- 그래서
List<BoardVO>의 리턴 타입을 두고 내부 코드를 수정합니다.
- 그래서
-
toString을 오버라이딩해서 사용합니다.
주의!
-
DAO안에서 검색 결과를 결정해버리면 활용성이 떨어집니다.
- 클라이언트에서 하도록 맡겨야 합니다.
Servlet vs JSP
HTTP Protocol
-
JAVA SE(Standard Edition) : 데스크탑, 서버, 임베디드 시스템 개발을 위한 플랫폼
-
JAVA EE(Enterprise Edition) : WAS(웹 어플리케이션 서버)의 지원으로 실행되는 시스템 개발을 위한 플랫폼
-
애플릿 : 보안이 너무 취약 ==> 서버에서 실행되는 애플릿 : 서블릿
-
서블릿 : 웹 상에서 요청된 서비스를 서버에서 처리하는 기술
-
JSP : 서블릿과 동일한 기술이지만 표현하는 방법과 역할이 다름
-
웹 서버의 종류
- 웹로직(WebLogic), 웹스피어(WebSphere), 제우스(Jeus), 제이보스(JBoss), 톰캣(Tomcat)
이클립스의 인코딩 변경 필요
- CSS, HTML, JSP 파일 모두 UTF-8로 변경을 적용하고 사용합니다.
-
webapp 폴더 내 HTML 파일을 만들고 테스트 합니다.
-
Tomcat 서버를 이클립스 내부에 설정 ==> 서버 설정을 ON/OFF 하기에 편함
-
HTTP 프로토콜
- 프로토콜 : 통신규약 = 데이터를 주고 받는 형식
-
웹 개발할 때 사용하는 것 : HTTP
-
통신 규약 : 한 번 설정하면 바꾸기 어려움
- 이클립스 validation 해제 방법
HTTP 요청 / 응답
-
브라우저는 URL, 하이퍼링크, 링크를 따라 다른 페이지로 이동 가능
-
startline, 메시지 헤더, 메시지 Body 영역에 값들을 채워줍니다.
-
메시지 헤더에는 수십가지 정보가 세팅이 됩니다.
-
메시지 Body에 사용자가 입력한 정보가 세팅이 됩니다.
-
HTTP 1.1 패킷 구조
-
Start Line : 상태줄
-
Header와 Body로 이루어짐
- GET VS POST
- URL vs URI
: 포트번호를 기준으로 그 뒷부분이 URI, 전체가 URL
-
HTTP 프로토콜 요청 정보는 브라우저가 만듬
-
HTTP 프로토콜 응답 정보는 서버가 만듬
Status Line
-
원래 404의 의미는
Not Found: 찾을 수 없어 -
405 : 님이 요청한 방식을 서버가 지원하지 않아
-
500 : 서버 오류
-
모든 서버가 포트가 다르다는 것을 알 수 있습니다.
- URL이란, 정확하게 원하는 자원(파일)을 찾아가기 위한 자원
-
.java가 아닌 web과 관련된 파일은 webapp 폴더 안에다 작성해야 합니다.
-
web.xml을 변경하고 나서, 서버를 재시작해주어야 합니다.
-
lib 폴더에, Java 압축파일들이 등록이 되어야 합니다.
-
POST 방식으로 요청하면 안전하다
-
Service 메소드는 GET이든, Post로 요청을 날리든 잘 실행이됨
-
Servlet이라는 기술은 서버에 종속된 기술
- 서버 안에 ServletContainer가 있음
-
Tomcat 서버 안에 생성
 -
서버 엔진 : 서블릿 컨테이너이다.
Servlet 작성 문법
- 특정 상황이 발생하면, 컨테이너가 자동으로 호출하여 실행되는 메소드를 의미합니다.
public LoginServlet(int cnt) {
System.out.println(" ====> LoginServlet 생성 ");
}=> Default 생성자가 없어짐
- 아래처럼 써야지
public LoginServlet() {
System.out.println(" ====> LoginServlet 생성 ");
}-
반드시 init에서 디폴트 생성자가 있어야 합니다.
-
init() 메소드: 멤버 변수를 초기화하기 위함-
서블릿은 디폴트 생성자만 작성할 수 있다.
-
그러면 멤버변수 초기화는 init 메소드가 담당하고 있음
-
-
브라우저에서 연속으로 요청하면 => 생성 이후에는 브라우저에 상관이 없이 service만 호출됩니다.
-
서블릿은 최초 요청 시간이 오래걸림, 2,3,4번째부터는 속도가 빠름
-
CTRL + SHIFT + /: XML 파일 주석처리 -
@WebServlet("/login")가 복잡한 xml 설정을 대신합니다!!!
response, request 객체의 메소드
- response
- setContentType
- sendRedirect
-
sendRedirect 방식은 URL이 변경되며, 2번 이상씩 실행됩니다. 속도가 감소하고 트래픽이 증가합니다.
- 이것을 보완학 위해 forward 방식이 등장!
-
응답 프로토콜 메시지 Body에다가, 서버에서 검색한 파일을 넣어주어야 함
- 그럴 때, 출력 스트림을 뚫어내는 작업이 response.getWriter();
-
출력 스트림을 얻기 전에 인코딩을 변경해야 합니다.
response.setContentType("text/html; charset=UTF-8");
PrintWriter out = response.getWriter();- 마찬가지로, service 메소드에서 사용자 정보를 추출하기 전에 인코딩을 먼저 처리해주어야 합니다.
request.setCharacterEncoding("UTF-8");
String title = request.getParameter("title");
String writer = request.getParameter("writer");
String content = request.getParameter("content");
-
getBoard.kt에 ?seq=로 상세 페이지 정보를 보여주어야 합니다.
-
String seq = request.getParameter("seq");-
문자열로 밖에 못 바꾸기 때문에 => 숫자로 변경하는 작업이 필요합니다.
-
Integer.parseInt(seq);을 통해서 String을 int로 바꾸어서 사용해줍니다.
-
