Keep going

검색 기능은 검색 조건과 키워드로 나누어 생각해 볼 수 있다. 검색 조건은 일반적으로 태그를 이용해서 작성하거나 를 이용하는 경우가 많다. 최근에는 일반 웹사이트에서 일반 사용자들의 경우에는 를, 관리자용이나 검색 기능이 강한 경우는 를 이용하는 형태가 대부분이다. 15.1 검색 기능과 SQL 게시물의 검색 기능은 다음과 같이 분류된다. 제목/내용/작성자와 같이 단일 항목 검색 제목 or 내용, 제목 or 작성자, 내용 or 작성자, 제목 or 내용 or 작성자 같은 다중 항목 검색 오라클은 페이징 처리에 인라인뷰를 이용하기 때문에 실제로 검색 조건에 대한 처리는 인라인뷰의 내부에서 이루어져야 한다. 단일 항목의 검색은 검색 조건에 따라서 칼럼이 달라지고 , LIKE 처리를 통해서 키워드를 사용하게 된다..

URL 파라미터로 정상적으로 원하는 페이지로 이동하는 것이 확인되었다면, 화면 밑에 페이지 번호를 표시해 사용자가 페이지 번호를 클릭할 수 있게 처리한다. - 페이지를 보여주는 작업- 브라우저 주소창에서 페이지 번호를 전달해서 결과를 확인하는 단계 JSP에서 페이지 번호를 출력하는 단계 각 페이지 번호에 클릭 이벤트 처리 전체 데이터 개수를 반영해서 페이지 번호 조절 14.1 페이징 처리할 때 필요한 정보들 현재 페이지 번호(page) 이전과 다음으로 이동 가능한 링크의 표시 여부(prev, next) 화면에서 보여지는 페이지의 시작 번호와 끝 번호(startPage, endPage) 14.1.1 끝 페이지 번호와 시작 페이지 번호 페이징 처리를 하기 위해서 우선적으로 필요한 정보는 현재 사용자가 보고 ..

페이징 처리를 위해서 필요한 파라미터는 1)페이지 번호, 2) 한 페이지에당 몇개의 데이터를 보여줄 것인지 결정되어야 한다. 페이지 번호와 몇 개의 데이터가 필요한지 별도의 파라미터로 전달하는 방식이 아닌 하나의 객체로 묶어서 전달하는 방식을 사용하겠다. org.zerkck.domain 패키지의 Criteria 클래스 (검색 기준) package org.zerock.domain; import lombok.Getter; import lombok.Setter; import lombok.ToString; @Getter @Setter @ToString public class Criteria { private int pageNum; private int amount; public Criteria() { this(..

목록 페이지는 기본적으로 페이징 처리가 필요하다. 상식적으로 수많은 데이터를 한 페이지에서 보여주면, 처리 성능에 영향을 미친다. 일반적 페이징 처리는 크게 번호를 이용하거나 계속 보기의 형태로 구현된다. 번호를 이용한 페이징 처리는 과거 웹 초기부터 이어오던 방식이고, 계속 보기는 Ajax와 앱이 등장한 이후에 무한 스크롤이나 더 보기와 같은 형태로 구현된다. 12.1 order by의 문제 데이터베이스를 이용할 때 웹이나 애플리케이션에 가장 신경 쓰는 부분은 1) 빠르게 처리 되는 것, 2) 필요한 양만큼만 데이터를 가져오는 것이다. 예를 들어, 거의 모든 웹페이지에서 페이징을 하는 이유는 최소한의 필요한 데이터만을 가져와서 빠르게 화면에 보여 주기 위함이다. 만일 수백 만개의 데이터를 매번 정렬을 ..

11.1 목록 페이지 작업과 includes 스프링 MVC 의 JSP 를 처리하는 설정은 servlet-context.xmll에 아래와 같이 작성되어 있다. Servlet-context의 일부 Colored by Color Scripter cs 스프링 MVC의 설정에서 화면 설정은 ViewResolver라는 객체를 통해 이루어지는데, 위의 설정을 보면 /WEB-INF/views 폴더를 이용하는 것을 볼 수 있다. /WEB-INF 경로는 브라우저에서 직접 접근할 수 없는 경로이므로 반드시 Controller를 이용하는 모델 2방식에서는 기본적으로 사용하는 방식이다. 게시물 리스트의 URL은 /board/list 이므로 최종적인 /WEB-INF/views/board/list.jsp가 된다. 11.1.1 SB..

영속 계층, 비즈니스 계층의 구현까지 모든 테스트가 진행되었다면 프레젠테이션 계층인 웹의 구현을 해야 한다. 10.1 Controller의 작성 스프링 MVC의 Controller는 하나의 클래스 내에서 여러 메서드를 작성하고, @RequestMapping 등을 이용해서 URL을 분기하는 구조로 작성할 수 있기 때문에, 하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성한다. 과거에는 이 단계에서 Tomcat(WAS)을 실행하고 웹 화면을 만들어서 결과를 확인하는 방식의 코드를 작성했다. 이 방식은 시간도 올래 걸리고 테스트를 자동화 하기에 어려움이 있다. 따라서 WAS를 실행하지 않고 Controller를 테스트할 수 있는 방법을 실습해보겠다. 10.1.1 BoardController의..

비즈니스 계층은 고객의 요구사항을 반영하는 계층으로 프레젠테이션 계층과 영속 계층의 중간다리 역할을 한다. 영속 계층 - 데이터베이스를 기준으로 설계 비즈니스 계층 - 로직을 기준으로 처리 예시) 쇼핑몰에서 상품을 구매한다. 해당 쇼핑몰의 로직이 '물건을 구매한 회원에게는 포인트를 올려준다' 고 하면 영속 계층의 설계는 상품과 회원으로 나누어 설계한다. 반면, 비즈니스 계층은 상품 영역과 회원 영역을 동시에 사용해서 하나의 로직을 처리하게 된다. 일반적으로 비즈니스 영역에 있는 객체들은 '서비스'라는 용어를 많이 사용한다. 9.1 비즈니스 계층의 설정 비즈니스 계층을 위해서 프로젝트 내 org.zerock.service라는 패키지를 작성한다. 설계를 할 때 각 계층 간의 연결은 인터페이스를 이용해서 느슨..

영속 계층의 작업은 항상 다음과 같은 순서로 진행한다. 테이블의 칼럼 구조를 반영하는 VO(Value Object) 클래스의 생성 MyBatis의 Mapper 인터페이스의 작성/XML 처리 작성한 Mapper 인터페이스 테스트 8.1 영속 계층의 구현 준비 거의 모든 웹 애플리케이션의 최종 목적은 데이터베이스에 데이터를 기록하거나, 원하는 데이터를 가져오는 것이 목적이기 때문에 개발할 때 어느 정도의 설계가 진행되면 데이터베이스 관련 작업을 하게 된다. 8.1.1 VO 클래스의 작성 VO 클래스를 생성하는 작업은 테이블 설계를 기준으로 작성하면 된다. 현재 tb1_board 테이블의 구성은 아래와 같다. 프로젝트에 org.zerock.domain 패키지를 생성하고, BoardVO 클래스를 정의한다. Bo..