JongHoon

[JunJongHun]

• 테스트 코드 작성 X
• swagger 예시 response 명세할 때, genric type 해결 못함

[dldmsql]

해당 클래스가 공통 응답 DTO라면 생성시각은 유효할 수 있지만, 수정시각과 삭제시각은 잘 사용되지 않을 거 같아요.
( + 논리 삭제 방식인가요.? 데이터가 삭제되었다면 삭제시각이 어디에 남을지가 궁금합니다. )

[JunJongHun]

리뷰 남겨주신대로 수정시각, 삭제시각은 거의 사용하지 않을 것 같긴 합니다!

baseDto를 만든 이유는 다음과 같습니다.

• entity를 만들 때, 공통적으로 사용되는 생성시간, 삭제시간, 수정시간을 상속 받아서 코드 중복을 줄이고 유지보수를 높이기 위해 사용한 것처럼, 반환을 할 때, 이 셋중에 포함해서 보내는 경우가 있을 것이라고 생각을 했습니다.

반환할 때, pick 또는 omit 등을 활용해서 코드 재사용성과 유지보수를 높이기 위해 만들었습니다!

---

데이터가 삭제가 된다면 deletedAt에 삭제 시간을 남기도록 했습니다. 기본으로 생성 될 때는 null 생성을 하여서, 데이터 삭제 여부는 삭제시간이 기록되어 있는가 없는가 입니다!

제가 질문에 대한 답을 잘 한건지 모르겠네요😂

[dldmsql]

저의 경우, 공통 응답 형식을 보통 정의할 때에는

1. status, code, message, data, createdat 을 담은 응답 객체
   2 페이징 응답 dto

두 가지입니다.

응답이 만들어져 도달하는 시각을 반환해서 특정 요청에 대한 응답에 오류가 있다면 그 시각을 이용해 대응하기도 합니다.

페이징의 경우, page, contents, size, sort 등 반복적으로 쓰이는 값들이 있어 글로벌하게 정의해두면 유용합니다.

[dldmsql]

삭제 여부를 기록할 때 날짜 데이터의 유무로 해도 좋지만, useYn 같은 플래그로 관리하면 좀 더 명시적이지 않을까 싶어요. 생성시각, 삭제시각 등은 일종의 메타 데이터여서 히스토리를 목적으로 하는 경우에 사용한다고 저는 생각하거든요.

[dldmsql]

user 데이터가 항상 존재한다고 보장할 수 없기에, 방어로직으로 아래와 같은 부분이 필요할 수도 있을 거 같아요.

if(user === null) throw new Exception('등록된 유저가 없습니다.')

[JunJongHun]

맞네요! 여러가지 상황에 대해서 예외처리를 꼼꼼히 해주는게 좋겠어요😄 개발하면서 예외처리는 참 중요하다고 생각하는데 가끔 놓치는 경우가 많네요😂

[dldmsql]

setter 방식 말고, 아래와 같이 할 수 있을 거 같아요.

return new HashtagEntity(hashtag);

생성자 방식으로 entity 클래스 안에 미리 어떤 데이터를 받을 건지 정의해둘 수 있을 거 같아요.

[JunJongHun]

오 그렇군요! 아직 여러가지 방법을 접해보지 못했는데, 새로운 방법을 알려주셔서 감사합니다! 생성자 방식에 대해서 알아봐야겠어요😄

[dldmsql]

스프링에서는 빌더 패턴이라고

var user = User().name(name).builder().build();

와 같이 표현하는 방법도 있습니다.

여러 디자인 패턴을 접해보고 적용해보는 것도 좋을 거 같아요😊