[TIL] Today I Lerned - 221220

[TIL] Today I Lerned - 221220

 

221220 - 기록

 

프로젝트

 

• Controller 단에서만 ResponseEntity를 사용, service 단에서 ResponseEntity가 아닌 dto 객체 사용
  • service단에서부터 ResponseEntity를 사용하게 된다면 추후에 해당 ResponseEntity에 너무 많은 데이터가 담기게 된다면 메모리의 과다 사용이 유발됨
  • Controller 단에서 반환 값을 ResponseEntity를 지정하더라도 Service단에서 dto, list를 반환하는 방식으로 먼저 가져오고 Contoller단에서 해당 값을 ResponseEntity로 넣어주는 방식
• Post 방식으로 데이터를 받아오고 저장하는 경우 
  • 해당 경우에는 데이터를 받아오고 저장한 후 client에게 header를 통해 해당 값이 저장이 되었다고 전달해야 한다.
  • Rest API를 구성할 때 client를 위해 지켜야 함
  • 이 부분이 없으면 Client는 본인이 보낸 값이 저장 유무를 파악할 수가 없다. 
• 댓글 API 작성
  • CRUD에 맞춰서 API를 작성
  • 다만 댓글의 조회 기능은 글에서만 조회가 가능할 수 있도록 PostController를 MainController로 이름을 변경하고 글을 조회하는 부분에 댓글 리스트를 가져와서 넣어주는 방식을 채택
  • 나머지 CUD의 경우 comment로 RequestMapping 하여 작성하고 service에서 메서드를 호출하는 방식을 선택
  • 다만 각 post와 comment의 구분선이 섞여서 이 부분을 다시 URI를 구성해야겠다는 생각을 하였다.
• 댓글, 글 출력
  • 글 하나에 달린 댓글을 동시에 출력하기 위해 자문을 구한 결과 해당 객체를 새로 만들어서 DTO를 구성

@Getter
@NoArgsConstructor
public class PostCommentDto {

    private String postTitle;
    private String postConetnets;
    private List<CommentResponseDto> commentList;

    public PostCommentDto(PostResponseDto postResponseDto, List<CommentResponseDto> commentResponseDtos) {
        this.postTitle = postResponseDto.getTitle();
        this.postConetnets = postResponseDto.getContent();
        this.commentList = Collections.unmodifiableList(commentResponseDtos);
    }
}

 

• DB
  • OneToMany, ManyToOne
  • 해당 경우는 외래 키를 설정하는 어노테이션
  • 이때 외래 키의 수정을 하게 되는 경우를 위해 키의 주인을 정하게 됨 → 외래키의 관리자 → 연관관계의 주인
  • 이때 키의 주인은 Many의 대상이 되는 곳
  • 선수, 팀이라는 테이블이 존재. 선수는 여러 명이서 팀에 속하게 됨
  • 이때는 선수 쪽에서 연관관계의 키를 관리한다.

전체적으로 과제를 다시 한번 리펙토링 한 날. 

각 리펙토링 사항은 위에 작성한 바와 같다