-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[3주차 과제] 차현민 #48
base: main
Are you sure you want to change the base?
[3주차 과제] 차현민 #48
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
카테고리 조작 메서드
필요하지 않다면 굳이 카테고리 조작 메소드를 넣지 않아도 될 것 같아요!
근데 왠만하면 필요할 것 같아요. 향후 직접 코드나 db수정 없이 admin이 카테고리를 추가하거나 삭제해야한다면 어쩔 수 없이 api call이 필요합니다. (사실 db를 사용했다는 것 자체가 향후 카테고리 수정 가능성을 본 것입니다.) 이때를 대비해서 미리 만들어두시면 좋을 것 같네요.
Entity의 @Builder
Entity에 @AllArgsConstructor
를 사용하시면 id를 포함한 모든 필드를 입력해야합니다. 특히 id는 @GeneratedValue
인데 직접 설정하는건 좋지 않은 것 같습니다.
@Builder
를 생성자에 붙여 사용하시면 원하시는 칼럼만 초기화하도록 유도할 수 있고, 명시적으로 인자를 줄 수 있어서 코드를 읽기 더 쉬워집니다.
주의하실점은 이때 @NoArgsConstructor
는 protected, 그 외의 생성자를 private으로 해주세요. 스프링에서 객체 생성에 필요한 생성자를 제외한 나머지는 모두 private으로 해두시는 것이 좋습니다. builder이외 다른 방법으로 객체를 생성하지 못하게 하는걸 권장드려요.
이번 주에 어떤 작업을 했는지 설명해주세요.
카테고리 구현과 피드백 받은 내용을 토대로 전체적인 코드 수정을 하였습니다.
특히 어떤 부분을 리뷰받고 싶나요?
카테고리를 구현했는데 카테고리 자체를 service층에서 새로 생성하고 삭제하는 메소드를 구현했는데 꼭 있어야 하나 궁금합니다.
이번 주는 어떻게 학습했나요? 아래 질문에 짧게 답변주세요!
이번 주에 학습에 투자한 시간
학습 하면서 좋았던 점과 아쉬웠던 점
어려움을 겪는 부분
스터디 개선되었으면 하는 점