개요
만들고 있는 메모장 프로젝트에 좋아요 기능이 필요했다. 먼저 작업에 들어가기 전에 이미 정의된 엔티티( 게시판 :Memo / 댓글 : Comments / 유저 : User )들과의 연관관계나 어떤 API로 받아야 할지를 고민했다.
1. API
좋아요 요청은 POST로만 사용한다. 요청이 들어왔을 때 올라가고, 다시 한 번 요청하면 내려가는 식으로 구성했다.
2. 연관관계
Likes 엔티티 하나로 만들어서 사용하면 연관관계가 너무 복잡해진다. 그래서 LikesMemo / LikesComment 로 나누어 사용했다.
연관관계는 위 항목들에 대해서 다대일로 처리했다. 다만 유저 부분은 양방향이 아닌 단방향이다. 컨트롤러에서 요청을 보낼 때 사용하는 userDetails를 사용해서 유저의 정보를 가져와(userDetails.getUser()) LikesRepository에 있는 유저의 중복 여부를 알 수 있기 때문에 유저 객체는 Likes 엔티티를 알 필요가 없다고 생각했다.
완성본
- 컨트롤러
위와 같은 형태, @PathVariable 로 특정 메모의 id를 받아서 그 메모에 좋아요를 올려주는 방식이다. userDetails로 유저의 정보를 가져온다.
- ResponseDto
컨트롤러 부분의 리턴 타입으로 ResponseDto를 사용했는데, 이 Dto 안에서는 memo가 가진 Likes엔티티의 리스트의 size를 int로 반환하여 필드로 사용한다.
위와 가팅 Memo가 List를 가지고 있기 때문. CascadeType은 REMOVE로 결정했다.
- Repository
Repository에서는 유저 id를 통해 특정 유저가 소유한 Likes를 조회 할 수 있는 findByUserId 매서드와
역시 마찬가지로 특정 유저가 중복해서 likes를 눌렀다면 delete할 수 있도록 하는 매서드를 만들었다.
- Service
if문에서 유저의 아이디로 repository에 등록된 좋아요가 있는지 확인한다. 그 후 비어있다면 추가하고, 이미 존재한다면 삭제한다.
더 알아보고 싶은 부분들
- repository에 Likes라는 객체가 계속 만들어지고 딜리트되고 하는 방식이 DB에 부담을 주진 않을까?
- 동시성 문제가 발생한다면? 서버가 트래픽이 너무 심하게 걸려서 한 유저가 동시에 3개요청을 줬는데 if가 안된다면? Likes가 3개 올라가고 다시 누를때마다 하나씩 내려와버리는 구조가 된다면?
-> 이부분은 다시 시도해가면서 포스팅 할 생각이다. - 연관관계에서 CascadeType을 원래는 Persist에 orphanRemoval = true 로 했다. 메모와 댓글의 관계도 양방향이고, 메모가 댓글을 가지고 있는데 이 두 녀석들은 저 위의 옵션이 정상작동한다. 그러나 Likes는 PERSIST를 주는 순간 오류가 발생. 왜 그럴까?
-> 이부분도 포스팅 할 예정.
