코드로 배우는 스프링 웹 프로젝트 Part3 (기본적인 웹 게시물 관리)

예제 작성에 앞서 스프링 MVC를 이용하는 프로젝트의 수성을 이해하는 일은 전체 데이터 흐름을 보기 위해 필요하다.브라우저에서 전송한 데이터를 스프링 MVC의 어떤 단계를 거쳐 실행되는지 이해한다면 문제가 발생했을 때 빠른 대처와 대안을 찾을 수 있다.일반적으로 웹 프

프로젝트를 진행하기 전 요구사항을 인식하고, 이를 설계하는 과정이 필요하다.이를 흔히 요구사항 분석 설계라고 하는데, 고객이 원하는 내용이 무엇이고, 어느 정도까지 구현할 것인가에 대한 프로젝트의 범위를 정하는 것을 목적으로 한다.요구사항은 실제로 방대해 질 수 있으므

예제를 위한 프로젝트는 'ex02' 이름으로 생성하고, 'Spring Legacy Project'로 생성한다.프로젝트를 생성한 후에는 pom.xml의 수정, 데이터베이스 관련 처리, 스프링 MVC 처리와 같은 순서로 진행한다.프로젝트를 생성 후 pom.xml에서 스플이

root-context.xml에는 mybatis-spring 네임스페이스를 추가하고, PART 1에서 작성한 DataSource의 설정과 MyBatis의 설정을 추가한다.root-context.xml은 내부적으로 Log4jdbc를 이용하는 방식으로 구성되어 있으므로 P

Java 설정을 이용한다면 pom.xml의 라이브러리 추가는 동일하지만 XML을 대신하는 클래스 파일이 필요하다.'jex02' 프로젝트를 작성했다면 프로젝트 생성 시 만들어진 XML 파일들을 삭제하고 org.zerock.config 패키지를 생성한다.Java 설정을 이

예제는 단순한 하나의 테이블만을 이용하기 때문에 데이터베이스에 테이블, 시퀀스, 약간의 데이터들이 생성되었다면 코드를 이용해 데이터에 대한 CRUD(Create, Read, Update, Delete) 작업을 진행한다.영속 계층의 작업은 항상 다음과 같은 순서로 진행한

웹 프로젝트 구조에서 마지막 영역이 영속 영역이지만, 실제로 구현을 가장 먼저 할 수 있는 영역도 영속 영역이다.영속 영역은 기본적으로 CRUD 작업을 하기 때문에 테이블과 VO(DTO) 등 약간의 준비만으로 비즈니스 로직과 무관하게 CRUD 작업을 작성할 수 있다.M

비즈니스 계층은 고객의 요구사항을 반영하는 계층으로 프레젠테이션 계층과 영속 계층의 중간 다리 역할을 하게 된다. 영속 계층은 데이터베이스를 기준으로 해서 설계를 나눠 구현하지만, 비즈니스 계층은 로직을 기준으로 해서 처리한다.예컨대, '쇼핑몰에서 상품을 구매한다.'고

BoardMapper와 BoardService, BoardServiceImpl에 대한 구조 설정이 완료되었으므로 'src/test/java' 밑에 org.zerock.service.BoardServiceTests 클래스를 작성해 테스트 작업을 진행한다.BoardServ

비즈니스 계층의 구현까지 모든 테스트가 진행되었다면 남은 작업은 프레젠테이션 개층의 웹 구현이다.웹은 PART 2에서 실습한 내용을 기준으로 현재 프로젝트에 반영한다.스프링 MVC의 Controller는 하나의 클래스 내에서 여러 메서드를 작성하고, @RequestMa

각 영역에 대한 모든 처리와 테스타가 완료되었다.만일 에러가 발생한다면 모든 문제는 화면 쪽에서만 발생한다고 말할 수 있다.화면에는 JSP와 JavaScript(jQuery), CSS, HTML을 이용해 작성한다.화면을 개발 하기 전 반드시 화면의 전체 레이아웃이나 디

list.jsp 페이지의 일부를 include 하는 방식으로 처리했음에도 많은 HTML의 내용들이 존재하므로 아래와 같이 최소한의 태그들만 적용시킨다.list.jsp에는 JSTL의 출력과 포맷을 적용할 수 있는 태그 라이브러를 추가한다.수정된 list.jsp를 저장하고

게시물의 등록 작업은 POST로 처리하지만, 화면에서 입력을 받아야 하므로 GET 방식으로 입력 페이지를 볼 수 있도록 BoardController에 메서드를 추가한다.register()는 입력 페이지를 보여주는 역할만을 하기 때문에 별도의 처리가 필요하지 않다.vie

게시물의 등록과 리스트 처리가 끝났다면 중요한 틀은 완성되었다.다음으로 목록 펭지에서 링크를 통해 GET 방식으로 특정한 번호의 게시물을 조회할 수 있는 기능을 작성한다.조회 페이지는 입력 페이지와 거의 유사하지만 게시물 번호(bno)가 출력된다는 점과 모든 데이터가

게시물의 수정 작업은 일반적으로 1) 조회 페이지에서 직접 처리하는 방식이나 2) 별도의 수정/삭제 페이지를 만들어 해당 페이지에서 수정과 삭제를 처리하는 방식을 많이 사용힌다.최근에는 게시물의 조회 페이지에서 댓글 등에 대한 처리가 많아지면서 수정과 삭제는 별개의 페

구현된 기능들 중 가장 미숙한 부분은 목록 페이지다.목록 페이지는 기본적으로 페이징(pagination) 처리가 필요한데 수많은 데이터를 한 페이지에서 보여주면, 처리 성능에 영향을 미친다.또한, 브라우저에서도 역시 데이터의 양이나 처리 속도에 문제를 일으키게 된다.일

데이터가 많은 상태에서 정렬 작업이 문제가 된다는 사실을 알았닫면, 이 문제를 어떻게 해결해야 하는지 살펴보려 한다.가장 일반적인 해결책은 '인덱스'를 이용해서 정렬을 생략하는 방법이다.'인덱스'라는 존재가 이미 정렬된 구조이므로 이를 이용해 별도의 정렬을 하지 않는

인덱스에서 가장 중요한 개념 중 하나는 '정렬이 되어 잇다는 점'이다.정렬이 이미 되어 있는 상태이므로 데이터를 찾아내 이들을 SORT 하는 과정을 생략할 수 있다.'bno의 역순으로 정렬한 결과'를 원한다면 이미 정렬된 인덱스를 이용해 뒤에서부터 찾아 올라가는 방식을

페이징 처리를 위해 역순으로 게시물의 목록을 조회하는 작업이 성공했다면, 이제는 전체가 아닌 필요한 만큼의 데이터를 가져오는 방식이다.오라클 데이터베이스는 페이지 처리를 위해 ROWNUM이라는 특별한 키워드를 사용해 데이터에 순번을 붙여 사용한다.ROWNUM은 쉽게 생

MyBaits는 SQL을 그대로 사용할 수 있기 때문에 인라인뷰를 이용하는 SQL을 작성하고, 필요한 파라미터를 지정하는 방식으로 페이징 처리를 하게 된다.여기서 신경 써야 하는 점은 페이징 처리를 위해 SQL을 실행할 때 몇 가지 파라미터가 필요하다는 점이다.페이징

페이징 처리는 브라우저에서 들어오는 정보들을 기준으로 동작하기 때문에 BoardController와 BoardService 역시 전달된느 파라미터들을 받는 형태로 수정해야 한다.BoardService는 Criteria를 파라미터로 처리하도록 BoardService 인터

URL의 파라미터를 이용해 정상적으로 원하는 페이지로 이동하는 것을 확인했다면, 화면 밑에 페이지 번호를 표시하고 사용자가 페이지 번호를 클릭할 수 있게 처리한다.페이지를 보여주는 작업은 다음과 같은 과정을 통해 진행한다.브라우저 주소창에서 페이지 번호를 전달해 결과를

화면에 페이징 처리를 위해 위와 같이 여러 정보가 필요하다면 클래스를 구상해 처리하는 방식도 편한 방식이 될 수 있다.클래스를 구상하면 Controller 계층에서 JSP 화면에 전달할 때에도 객체를 생성해 Model에 담아 보내는 과정이 단순해지는 장점도 있다.org

JSP에서 페이지 번호를 출력하는 부분은 JSTL을 이용해 처리할 수 있다.SBAdmin2는 부트 스트랩 기반으로 구성되어 있기 때문에 https://v4-alpha.getbootstrap.com/components/pagination/와 같이 부트 스트랩 관

목록 화면에서 페이지 번호를 클릭하면 정상적으로 원하는 페이지로 이동하는 것을 볼 수 있지만, 몇 가지 문제가 있다.우선 사용자가 3페이지에 있는 게시글을 클릭한 후 다시 목록으로 이동해 보면 다음과 같이 무조건 1페이지 목록 페이지로 이동하는 증상이 일어난다.페이지이

modify.jsp에서는 < form > 태그를 이용해 데이터를 처리한다.거의 입력과 비슷한 방식으로 구현되는데, 이제 pageNum과 amount라는 값이 존재하므로 < form > 태그 내에서 같이 전송할 수 있게 수정해야 한다.modify.jsp 역시

페이지의 이동이 모든 작업에서 정상적으로 이루어지는 것을 확인했다면 최종적으로는 데이터베이스에 있는 실제 모든 게시물의 수(total)를 구해서 PageDTO를 구성할 때 전달해 주어야 한다.전체의 개수를 구하는 SQL은 어렵거나 복잡하지 않기 때문에 어노테이션으로 처

게시물 관리에서 마지막은 다양한 검색처리다.검색 기능은 다시 검색 조건과 키워드로 나누어 생각해 볼 수 있다.검색 조건은 일반적으로 < select > 태그를 이용해서 작성하거나 < checkbox>를 이용하는 경우가 많다.과거에는 < checkbox

SQL문에서 느끼는 점은 검색 조건이 변하면 SQL의 내용 역시 변하기 때문에 XML이나 어노테이션과 같이 고정된 문자열을 작성하는 방식으로는 제대로 처리할 수 없다는 사실이다.다행히 MyBatis는 동적(Dynamic) 태그 기능을 통해 SQL을 파라미터들의 조건에

페이징 처리에 사용했던 Criteria의 의도는 단순히 'pageNum'과 'amount'라는 파라미터를 수집하기 위해서다.페이징 처리에 검색 조건 처리가 들어가면 Criteria 역시 변화가 필요하다.검색 조건을 처리하기 위해서는 검색 조건(type)과 검색에 사용하

화면에서 검색은 다음과 같은 사항들을 주의해서 개발해야 한다.페이지 번호가 파라미터로 유지되었던 것처럼 검색 조건과 키워드 역시 항상 화면 이동 시 같이 전송되어야 한다.화면에서 검색 버튼을 클릭하면 새로 검색을 한다는 의미이므로 1페이지로 이동한다.한글의 경우 GET