- 정경일
- dto에 생성자가 없으면 뷰에서 파라미터를 못받아온다... 삽질...
- 도메인으로 패키지구조를 짤 경우 더 깔끔하고 명확하게 짜야한다..
- 프로젝트 전반에 대한 이해가 보다 더 필요한듯...
- 김승은
- codepen 공유
- RowMapper 여러개 정의 어려움 공유
- validation 어느 계층까지 하나
- 검색 시 쿼리 조작
- Response Format 쓰는 이유 : API 문서 가독성 있게 만드는 의의
- service에서 service를 지양하는 이유 : 순환참조 발생할 수 있음. / 계층 구조 명확하면 가능
- 박상혁
- 특정 조건으로 조회할 때 다 불러온 다음 어플리케이션에서 필터 처리 ← 절대 하지마라
- DTO 어디까지 내려올 것인가? Controller VS Service
- Service까지 내려오면 service간 method 참조 시 dto를 써야한다는 문제
- 애초에 Service 간 연관 관계를 최대한 지양하는 것이 좋다!
- 의견이 분분한 문제라 지금 당장 결론짓기는 힘든 문제인듯 하다.
- Rest API 응답에 ResponseEntity를 씌워줄 필요성?
- status를 body에 안담아도 받는 쪽에선 status 확인이 가능한데, 굳이 씌울 필요가..?
- 팀원들끼리 response 양식을 맞춤으로써 추후 문서화도 더 간편하게 할 수 있고 일관성 있는 코딩을 지향할 수 있지 않을까?
- 생각보다 긍정적인 효과가 있는 것 같음.
- 정현서
- 조건별로 조회할 때 controller, service, repository에서 어떻게 구현했는지?
- 정현서: repository에서 query string을 조건(파라미터) 유무에 따라 변경 → controller, service, repository에 메소드 하나씩으로 만들어서 함
- 김승은: 조건별로 메소드를 따로 만들게 되면 조건들의 조합에 따라서 메소드의 수가 굉장히 많아질 수 있음. 메소드 하나로 쿼리를 조작하는게 맞는 것 같음.
- 박상혁
- 홍유석: 조건별로 메소드 따로 구성
- 정경일: 죄송합니다,,, 게더가 끊겨서 못들었습니다ㅜㅜ 나중에 보시면 이 부분 채워주실 수 있을까요??
- 홍유석
- DTO 작성에 대하여
- 빌더 패턴은 인자 몇개일 때 부터 사용하는지?
- 코딩 스타일
- 팀이 공통적으로 따르는 패키지 구조를 가지는게 어떨까?
모든 부분에서 DTO를 만들다 보니 DTO의 수가 너무 많아지는데 다른 사람들은 어떨까?
4~5개 정도 부터 빌더 패턴 사용
if문 사용하고 중괄호 닫는게 좋은거 같다
아직은 그럴 필요가 없는거 같다