거니의 velog

* 상품 API의 경우 파일 데이터가 추가된다는 점을 제외하면 JSON을 이용하는 데이터 처리방식과 유사하다. 하지만 파일 데이터가 추가되기 때문에 처리 과정에 걸리는 시간에 맞는 모달창을 보이는 등의 추가적인 부분이 필요하다. 이 장에서는 컴포넌트의 재사용을 이용해서 이러한 처리를 연습한다. * 이번 장의 개발 목표는 다음과 같다. 1. 파일이 추가되는 데이터 처리 2. 기존 공통 컴포넌트의 재사용 1. 상품 관련 React-Router 설정 * 개발하려는 상품 기능은 목록 화면에서 새로운 상품을 등록할 수 있고, 조회 화면에서는 수정/삭제 화면으로 이동이 가능하도록 구성해야 한다. 상품 등록 시에는 상품의 이미지들과 함께 추가해서 등록하게 된다. * 상품 목록 페이지는 상품들의 이미지를 같이 보여주고..

(4) 수정 기능의 처리 * 수정 기능의 처리에서 첨부파일의 처리를 주의해야 한다. ProductDTO에서는 List 타입으로 선언된 files가 존재하고, List 타입은 uploadFIleNames가 존재하는데 uploadFIleNames는 기존에 업로드된 파일들의 이름을 의미하고, files는 처리가 필요한 새로운 파일들이다. 실제 데이터베이스에 추가되는 것은 문자열로 된 uploadFIleNames 이므로 업로드 작업이 완료된 후에는 이미 업로드된 uploadFIleNames에 업로드된 파일의 이름들을 추가해서 구성해 주어야 한다. * 데이터베이스에 관련된 엔티티에서는 uploadFIleNames의 내용이 첨부파일의 이름들이기 때문에 기존의 Product 객체가 가진 모든 파일을 지우고, Prod..

(3) 조회 기능의 처리 * 조회 기능은 등록 기능과 반대로 Product와 List로 구성된 데이터를 하나의 ProductDTO로 변환해야만 한다. [서비스 조회 기능의 처리] * ProductService 인터페이스에는 파라미터로 상품의 번호(pno)를 받고, 리턴 타입은 Product의 타입인 get()을 정의한다. package com.unlimited.mallapi.service; import org.springframework.transaction.annotation.Transactional; import com.unlimited.mallapi.dto.PageRequestDTO; import com.unlimited.mallapi.dto.PageResponseDTO; import com.unl..

(2) 등록 기능의 처리 * 서비스 계층에 대한 테스트 코드를 작성해 보자. 테스트용 데이터는 실제 이미지가 아니기 때문에 화면에서 이미지 파일들이 제대로 보이지 않는 단점이 있기는 하지만, 서비스 계층이 정상적으로 동작하는지 확인할 수 있고 컨트롤러와 연동이 완료되면 정상적으로 이미지 파일들의 업로드를 확인할 수 있게 된다. [서비스 등록 기능의 처리] * ProductService는 등록 처리를 위해서 ProductDTO를 Product와 ProductImage 타입의 객체들로 만들어서 처리해야 한다. 이전 예제와 달리 직접 코드를 통해서 DTO를 엔티티 객체로 변환한다. * ProductService 인터페이스에 register() 메서드를 추가한다. package com.unlimited.mall..

4. 서비스 계층과 컨트롤러 연동 * 서비스 계층에서는 DTO와 엔티티 간의 변환에 주의하면서 기능들을 구현한다. service 패키지 내에 ProductService 인터페이스와 ProductServiceImpl 클래스를 추가한다. (1) 목록 기능의 처리 * 선언된 클래스와 인터페이스에서는 가장 구현이 복잡한 목록 기능을 구현해 본다. ProductService 인터페이스 목록에 PageResponseDTO로 처리하는 getList()를 추가한다. package com.unlimited.mallapi.service; import org.springframework.transaction.annotation.Transactional; import com.unlimited.mallapi.dto.PageRe..

3. 엔티티 처리* 파일 업로드의 특징은 파일 자체가 부수적인 요소라는 점이다. 예를 들어, 상품 등록의 경우 핵심은 상품 자체이고 파일들은 이를 설명하는 부수적인 데이터이다. 이럴 때 상품은 고유한 PK를 가지는 하나의 온전한 엔티티로 봐야 하고 파일들은 엔티티에 속해 있는 데이터로 봐야 한다. * JPA에서는 '값 타입 객체'라는 표현을 쓰는데 컬렉션으로 처리할 때는 @ElementCollection을 활용한다. 값 타입 객체는 엔티티와 달리 PK가 없는 데이터이다. 예제에서 하나의 상품 데이터는 여러 개의 상품 이미지를 갖는 1:N 관계이다. * domain 패키지에 Product 엔티티 클래스와 ProductImage 클래스를 추가한다.* ProductImage는 @Embeddable 어노테이션을..

* 간단한 Todo 예제로 프로젝트의 기본 구성을 경험했다면 이제는 조금 주의해야 하는 데이터를 다룰 것이다. 이번 장에서는 첨부파일이 여러 개 포함되는 상품 데이터를 예제로 다룬다. 상품 데이터는 첨부파일을 같이 처리하기 때문에 썸네일 이미지의 생성이나 데이터의 구조가 기존과 달라지게 된다. * 이번 장의 개발 목표는 다음과 같다. (1) 파일 업로드와 다운로드 처리 (2) 하나의 상품에 여러 이미지를 가지는 데이터 처리 (3) 첨부파일이 있는 API 개발과 테스트 1. 파일 업로드를 위한 설정 * 파일 업로드에 필요한 모든 기능은 이미 스프링 Web 관련 라이브러리에 존재하므로 프로젝트의 application.properties에는 이와 관련된 설정을 추가한다. * 예제에서는 프로젝트의 실행 폴더에 ..

7. 수정/삭제 처리 * 수정/삭제 화면은 기존의 ModifyPage와 새롭게 작성할 ModifyComponent를 이용해서 처리한다. 코드를 구현하기 전에 수정/삭제 후에는 어떤 식으로 동작해야 하는지를 정리해 본다. - 삭제(Delete 버튼) : 삭제 결과를 모달창으로 보여주고 '/todo/list'로 이동 - 수정(Modify 버튼) : 수정 결과를 모달창으로 보여주고 '/todo/read/번호'로 이동 * 수정/삭제 기능 모두 서버의 호출 결과를 이용해서 모달창을 보여주는 점은 공통적이고 이후의 이동 경로에서 차이가 난다. (1) 수정/삭제 호출 기능 작성 * api/todoApi.js에는 수정과 삭제에 필요한 함수들을 추가한다. import axios from "axios"; export co..

6. 등록 컴포넌트와 모달창 처리 * 지금껏 작성한 조회나 목록 기능과 달리 남은 기능들은 다음과 같은 공통점이 있다. - GET 방식이 아니라 POST/PUT/DELETE와 같이 다른 방식으로 호출 - API 서버 호출의 결과가 주로 성공/실패와 같은 단순한 결과 - 처리 후 다른 경로로 이동하는 경우가 많음(리다이렉트) * 과거의 서버사이드 프로그래밍은 서버에서 처리한 후에 결과 메시지를 모두 만들어서 전송하거나 PRG(Post-Redirect-Get) 방식으로 다른 경로를 호출하는 방식이었다. 리액트와 같은 애플리케이션에서는 기본적으로 모든 처리는 현재 화면을 중심으로 처리된다. 현재 화면에서 서버를 호출하고 결과 역시 현재 화면에서 처리하고 이후에 이동하는 방식이다. * 등록 처리는 입력하는 화면..

5. 목록 데이터 처리 * 조회는 단순하게 서버의 데이터를 보여주는 기능만으로 구현할 수 있지만, 목록 데이터는 페이지 처리나 여러 링크 등이 추가되어서 더 복잡한 구성을 하게 된다. 가장 먼저 구현할 기능은 브라우저 경로에 있는 쿼리스트링으로 페이지 번호/사이즈에 따라서 서버를 호출하고 결과를 출력하는 것이다. (1) 목록 데이터 가져오기 * 해당 데이터를 가져오는 기능은 useEffect()를 사용해서 구현하는 것으로 컴포넌트는 components/todo 폴더 내에 ListComponent로 작성한다. * ListComponent는 useCustomMove()를 이용해서 현재 경로의 page와 size를 구성하고 API 서버를 호출한다. 서버의 데이터는 dtoList라는 배열 데이터와 pageNum..