인프런 커뮤니티 질문&답변
작성한 질문수
변경 감지를 통한 데이터 수정할 때 추가, 삭제는 어떻게 처리해야 할까요?
작성
·
159
·
수정됨
0
안녕하세요. 데이터 수정은 변경 감지로 처리하는게 적절한걸로 강의를 통해 이해했습니다.
강의를 학습 후, 상품 정보를 수정하는 API를 개발하고 있습니다.
상품 정보 업데이트를 진행할 때 옵션 목록과 같은 하위 데이터에 대해 추가, 삭제는 어떤식으로 로직을 처리해야 하는게 적절한지 판단이 안되어 질문 드립니다.
클라이언트에서 상품 정보 수정 API를 호출할 때, 생각한 프로세스는 아래와 같습니다.
- 수정하는 옵션의 경우 ID와 변경되는 데이터를 필드에 담아서 보내줍니다.
- 신규 옵션을 추가하는 경우에는 ID를 제외한 추가될 데이터를 필드에 담아서 보내줍니다.
- 삭제하는 옵션은 필드에 담지않고, 수정/신규 옵션만 필드에 담아서 보내줍니다.
수정 API 개발할 때, 어떤식으로 처리하는게 좋은 방법인지 궁금하여 질문 드립니다.
(수정 옵션) 상품 정보 업데이트 시 기존 옵션 데이터의 경우에는 ID로 데이터를 조회 후 변경 감지로 필요한 데이터만 수정하도록 했습니다.
(추가 옵션) 신규 옵션 데이터는 ID 값이 없는걸 식별해서 추가하도록 로직을 짜는게 적절 할까요?
(삭제 옵션) 기존 옵션 데이터를 삭제하고 싶습니다. 클라이언트에서 API로 옵션 정보를 넘겨주는데, 삭제되는 옵션은 넘어오지 않습니다. 이런 경우에는 ID가 식별되지 않아 변경 감지로 삭제할 수가 없을거 같은데 어떻게 해야할까요? (삭제는 soft delete 방식으로 처리해야 합니다.)
삭제되는 ID 값을 deleteOptionIds 같은 필드로 따로 받아서 처리하는게 적절 할까요?
감사합니다.
답변 2
0
안녕하세요. Anonymous님, 공식 서포터즈 코즈위버입니다.
아이템과 아이템옵션이 1:N 으로 관게를 맺고 있다고 하면,
옵션 수정은 말씀하신 것처럼 옵션을 조회하여 변경된 내용을 '아이템옵션' 엔티티에 반영하면 변경감지로 업데이트가 됩니다.
옵션 추가는 '아이템옵션' 엔티티를 새로 생성하여 아이템과 관계를 맺으면 (강의에서 추천하듯 관계메서드를 이용하여 addItemOption(ItemOption itemOption); 이 또한 자동으로 insert 쿼리가 발생합니다.
삭제의 경우 소프트삭제가 필요하다고 하셨는데, 그렇다면 이는 업데이트와 동일한 처리입니다. 다만, 삭제한 아이템 옵션이 프론트에서부터 제외된 채로 넘어온다면, 백엔드에서 루프를 돌며 어떤 아이템 옵션이 삭제된 것인지 찾는 과정이 필요합니다. 대충 아래와 같은 프로세스를 따라야 합니다.
클라이언트에서 넘긴 아이템 옵션의 아이디 배열 A
아이템이 보유한 옵션아이템의 아이디 배열 B
A와 B를 비교, B에는 존재하나 A에는 없는 아이템옵션 아이디만 배열C로 추출
배열C를 루프 돌며 삭제플래그 Y로 수정
이는 백엔드에서 비효율적인 조회와 비교가 계속 발생할 수 있으므로, 프론트 로직을 변경하는 것이 적절해보입니다. 사용자가 브라우저에서 아이템 옵션을 [삭제] 하는 순간 통신을 시도 하여 해당 아이디의 아이템옵션 삭제플래그를 변경하는 것이 좋아보입니다.
감사합니다.
안녕하세요 Anonymous 님!
상품을 [저장] 하는 순간 모든 변경점을 일괄반영하는 것이 회사나 프로젝트의 룰이라면 어쩔수 없이 모든 값을 비교하는 프로세스가 필요합니다.
상품상세 화면은 경우에 따라 수정이 빈번하게 발생할 수 있는데요, 그때마다 모든 비교를 하면 비효율이 발생하기에, 2~3개 정도로 분리하여 저장하는 기능을 제공하기도 합니다.
'상품 기본정보', '재고', '가격', '옵션', '상품DB'(이미지파일) 등으로 분리하여 상품 전체가 아닌 부분 부분만 즉지 저장할 수 있도록 UI를 제공하기도 합니다. 그러나 회사 규정에 따라 포기해야 할 수 있습니다.
감사합니다.
프론트에서 그런 형태로 값을 전달해줄 수 있다면 가능합니다.
삭제할 상품옵션 아이디만 배열로 받아서, 이를 루프 돌면서 아이디와 일체하는 상품옵션의 삭제플래그 값을 변경하도록 하시면 됩니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
Anonymous님께서 주신 질문에 대해 답변드리겠습니다.
수정 옵션 처리:
기존 옵션 데이터의 경우, 말씀하신 대로 ID를 사용하여 데이터를 조회하고, 필요한 필드만 변경 감지를 통해 수정하는 방식이 적절합니다. 이는 JPA의 엔티티 상태 변경 감지를 활용하여 데이터베이스 업데이트를 효율적으로 처리할 수 있습니다.추가 옵션 처리:
신규 옵션 데이터는 ID가 없는 것으로 식별하여 추가하는 방식이 적절합니다. 이 경우, 클라이언트에서 ID가 없는 데이터를 신규 데이터로 판단하고 이를 데이터베이스에 저장하면 됩니다. 적절한 생성자나 메서드를 사용하여 엔티티를 생성하고persist상태로 만드는 것이 좋습니다.삭제 옵션 처리:
소프트 삭제 방식이라면, 삭제할 데이터를 식별해서 실제 삭제가 아닌 ‘삭제 플래그’를 설정하는 것이 필요합니다. 클라이언트에서 삭제할 옵션에 대한 ID 목록을deleteOptionIds와 같은 별도의 필드로 받아서 이를 기반으로 소프트 삭제를 처리하는 방식이 적절합니다. 이렇게 하면 엔티티의 ‘삭제된’ 상태를 표현하는 플래그를 업데이트하여 소프트 삭제를 구현할 수 있습니다.
이미지 설명과 더 많은 정보는 아래 출처를 확인해주세요:
스프링 부트 3.0 참고문서
추가적인 질문이 있다면 언제든지 문의해 주세요. 감사합니다!
안녕하세요. 답변 감사합니다.
답변을 주신 내용 중 궁금한 부분이 있어서 질문드려요.
[삭제]를 하는 순간 통신을 시도하여 삭제 플래그를 변경하게 된다면, 수정 페이지에서 사용자가 [저장] 버튼을 안누르고 수정 화면을 이탈한 경우에는 [삭제]가 반영되면 안된다고 생각이 되어집니다.
화면을 이탈하는 경우에는 변경된 삭제 플래그를 원복해야 하는데, 해당 부분은 어떻게 처리가 되어야 할까요?