Java 자바 웹 프로그래밍: Spring, CRUD
화면에 다 뿌릴 필요가 있었을까. 오라클을 이용하면 그럴 필요가 없었겠죠. 제로보드라고 하죠.
URL 페이지 번호에 음수를 넣으면 쿼리문이 다 나오는 에러가 발생.
쿼리문 날리는 부분에서 좀 더 보완을 할 수 있어요.
한 페이지에 10개, 10페이지 출력 (100개의 게시물 찾는 쿼리문)
101개의 게시물이 있으면 ">>" 다음 페이지 리스트 출력.
select
rn, bbsno, title, writer, regdate, cnt
from
(
select /*+INDEX_DESC(tbl_mp3, pk_mp3) */
bbsno, title, writer, regdate,
count(bbsno) over()
from tbl_bbs
where bbsno > 0
and rownum <= (CEIL((page / 10))*100)+1)
)
rn> ((2-1)*10) and rn <=(2*10);
|
Count() over() 의 사용. 내부에서 집합함수 다시 사용한 것.
원글 데이터 뿐만 아니라 게시글에 필요한 숫자까지 한 번에 가져온 것.
내부적으로 Count (StopKey)가 들어가기 때문에 숫자 세는 것까지 들어간다.
요즘 나오는 게시판들은 맨 마지막으로 가는 버튼을 사용하지 않는다. (느려지기 때문에)
VO에 항목이 새로 생기면, VO를 새로 만들지 않고, 상속을 사용해서 추가하는 방법이 있다.
데이터 베이스에서 속도가 느려지는 부분은 검색이에요.
보니까 페이지 번호를 무는 게 어려운 경우가 많은 것 같아요.
일단은, 현재페이지(2)가 필요해요.
카운트(101)
라인 디스플레이(10)
페이지당 사이즈(게시물의 개수) (10)
위의 쿼리문에서 100+1 부분은
라인 디스플레이 * 페이지당 사이즈
-- 강사님 코딩 부분
PageMaker 유틸부터 제작. 변수 선언하고, 생성자 작성. 생성자를 오버로딩으로 3가지 경우를 작성. 파라미터 0~2개인 경우. Getter, setter, toString. 제작. 생성자 호출하기 전에는 다른걸 호출하지 못한다. 문자열 던져서 숫자로 바꾸어주는 static 메소드 선언.
서블릿-> Controller 생성.
<필기그림1>
<ul>과 <li> 태그 사용해서 리스트 .jsp파일에서 작성. 최대한 UI는 바보스럽게 코딩 해줘야 해.
Hasnext와 hasprev를 계속 만들어 내는 이유는 같은 리스트에서 계속 쓰기 위해서.
이번 시간에 했던 부분.
- 가능하면, 테이블 스캔을 어려 번 쓰지 마라.
- 자바의 객체를 써먹어라. UI를 최대한 바보스럽게 코딩해라.
검색어를 입력해서 검색을 했을 때, 여러 페이지가 나올 수 있다. 이 때, 페이지 전환은 검색 조건을 유지한 상태로 넘어가야 하는 문제가 발생한다. 이 때는, <a> 태그의 링크가 엄청 복잡해 질 수 밖에 없다. 때문에 검색조건 필터링을 하는 사이트(예. 다나와)에서는 이를 컨트롤하는 것이 어려울 수 있다.
재사용하기도 어렵고 허접한 인터넷에 돌아다니는 게시판 소스말고. 이런거에 익숙해지라는 거에요.
전부 이해하지 못해도 괜찮아요. 번호를 클릭하면, hidden값만 바꾸고 submit을 날려버려.
<a href = 'javascript:_goPage(1)'>1</a>
자바스크립트를 만들고 Function의 _goPage() 생성. 값 전달.
모든 링크가 _goPage()로 만들고 _goPage()부분만 오버라이드 하면 된다.
PageMaker가 검색조건을 다 물고 있으면 페이지 구분 부터, 검색어 무는 것 까지 전부 처리가능.
이렇게 만들어진 소스는 include를 사용하면 재사용성이 증가한다.
PageMaker가 VO다. List 출력. 검색조건을 파라미터로 받아들인다면
게시판에서는 CRUD List가 전부야.
검색기준 Criteria를 가지는 객체생성.
Generic_DAO 생성.
CRUD에 List추가 - Public List <E> list(Criteria cri) throws Exception;
동작하는 기능을 파라미터로 던져줄 수 없으니까. 어쩔 수 없이 람다식이 나올 수 밖에 없는 것.
3단 구현: Interface -> 추상클래스 -> 구현
인터페이스마다 따로 구현해야하는 문제점에 직면한다. 이 문제를 자바에서는 해결할 수 없어요.
SQL Executor를 매번 바꿔야 할 문제. 해결할 수 있는 방안 -> My batis
이런 좋은 기능들은 여러 번 반복 작업을 해봐야 얼마나 좋은지 알게 된다.
My batis 는 한국에서만 열심히 사용 ㅠ ㅠ (전자정부 프레임워크)
쿼리문이 전부 XML로 빠지고 여기에서 값을 준다.
적당한 SQL과 적당한 파라미터만 던져주면 파라미터 세팅해주고 Resultset도 해결해준다.
파라미터를 자동으로 세팅해주고 결과데이터를 자동으로 처리해주는 녀석이 있다면, 우리는 게시판을 좀 더 쉽게 만들 수 있지 않을까. 목표를 DAO에 코딩을 넣지 않는 것. 무배포. 무코딩. 무설정.
원래 mybatis는 Spring하고 같이 써요.
// 일단 오늘 한 코드가 어떻게 돌아갔는지.
// 우리 팀이 왜 결과가 안 나왔는지 분석 할 것. 다음에 만들면 어떻게 빨리 만들 것인가. 내가 뭘 할 것인가.
'Programming 프로그래밍' 카테고리의 다른 글
비트컴퓨터 jQuery ajax json (2) | 2018.02.22 |
---|---|
Java 자바 웹 프로그래밍: Spring, Mybatis vs JPA vs Hibernate (0) | 2018.02.20 |
Java 자바 웹 프로그래밍: <켄트 벡의 구현패턴> 데이터 오브젝트 DTO, VO (0) | 2018.02.19 |
2014-10-19 <Java Script for Web Developer> 책 4, 5, 10, 11장 요약 (0) | 2018.02.19 |
2014-10-19 <Java Script for Web Developer> 1~6장 요약본 (0) | 2018.02.19 |