모든 리뷰에 User를 넣어서 기능을 완성했다.
ResponseDTO가 순서가 뒤죽박죽이라 일관성 있게 수정했다.
주문을 담당하고 있는 팀원을 도와 주문 조회 기능을 구현했다.
주문 삭제 기능을 구현했다.
오늘 알게된 것
DTO를 최소한의 데이터로 전달하게끔 변경
User 객체 자체를 넘기기보다는 UserId로 UserName만 검색해서 넘기는게 더 낫다.
엔티티 동등성 : ID끼리 비교하는거 지금은 상관없을거같은데
나중에 객체 동등성을 비교할 때 문제가 될 수 있다.
아직 save하지 않은 엔티티는 ID가 아직 없으니까
그때는 동등성 비교는 ID로 할 수 없다.
그래서 ID 말고 userName, 이메일 이런거로 비교하라는 말이였음.( = Business Key)
엔티티를 삭제하면 안됌
삭제한 엔티티를 따로 보관을 하던가
아니면 true false를 해서 분류를 하던가 해야함
-> hard delete(delete 명령어) / soft delete(논리적 삭제, update 명령어)
userDetails.getUser().getUserId() 는 보기 힘들다고 한다.
-> User user = userDetails.getUser();
user.getUserId(); 로 분리하는게 낫다.
또한 . 을 여러개 쓰지 않는게 좋다.
allowcation size = default가 50
id가 늘어날 때 50씩 늘어나게끔 하는것
-> 추가 검색 필요
repository에서 쿼리메소드를 통해 List로 반환받을 수 있다.
이를 통해 orderGameList를 반환받아 그 안의 게임Id들을 조회 해 올 수 있다.
List<OrderGame> orderGameList = orderGameRepository.findAllByOrderId(orderId);
List<OrderGameDTO> orderGameDTOList = new ArrayList<>(); // <- 이부분
for (OrderGame orderGame : orderGameList) {
Game game = gameService.findById(orderGame.getGameId());
OrderGameDTO orderGameDTO = OrderGameDTO.of(game, orderGame.getOrderCount());
orderGameDTOList.add(orderGameDTO);
}
처음에 생각한것은 Map을 통해서 같은 의상 종류끼리 뭉치고, 그 안에 의상 정보를 넣으려고 했는데
중복 Map이 안되기 때문에 List를 통해서 넣으려고 했다.
하지만 데이터를 막상 넣어보니 hat : 1번모자 / hat : 2번모자 이렇게 들어가는게 아니라
hat : 1번모자2번모자 이런식으로 들어가서 분리를 할 수가 없었다.
결국 1시간 30분동안 시간을 소비하고 다른 사람의 풀이를 통해 제출했다. ㅠㅠ
다른사람은 숫자로 치환해서 풀었던데 너무 아쉬웠다.