feat/#6-seminar3-essential

[2hyunjinn]

🛠 Related issue

• closed [feat] seminar3 - 필수 과제 #6

📌 필수 과제

✅ 일기장 필수 기능 구현

• 일기 조회 기능
• 일기 작성 기능
• 일기 수정 기능
• 일기 제거 기능
• 회원가입 기능
• 로그인 기능

📌 선택 과제

✅ 일기장 선택 기능 구현

• 일기 목록 조회시 페이징 처리

---

🌀 구현 내용

💡일기 작성 기능

• 카테고리 추가 (일기 카테고리는 4개 - 음식, 학교, 공부, 운동)
• 하나의 일기는 하나의 카테고리만
• 일기 글자수는 30자 이하로 제한 (이모지나 태국어 등 고려 없이 그냥 단순하게 String length 값의 비교로만 30자)
• 제목과 본문은 blank 가 될 수 없음
  (제목 : 최소 1자 ~ 최대 10자 - 다른 일기와 중복 방지)
  (본문 : 최소 1자 ~ 최대 30자)
• 공개하기 기능 추가

💡일기 조회 기능

• 카테고리별 조회 기능 추가
• 내가 쓴 일기 조회 기능 추가 (내가 쓴 일기는 공개여부 상관없이 모두 뜨게 함)
• 비공개 일기는 전체 조회에서 제외
• 전체 일기 / 내가 작성한 일기 / 카테고리 별 조회 모두 정렬 순서 동일하게 유지
• 전체일기 조회 시 responsebody에 작성자 닉네임 추가

💡회원가입 및 로그인 기능

• 회원가입 시 username 중복 방지
• 회원가입 기능
• username과 password로 로그인

🤧 트러블 슈팅

1. 파라미터로 카테고리를 입력받지 않아도 다이어리를 보여주고 싶은데, 파라미터에 카테고리를 넣지 않으면 서버 오류가 뜸
2. 잘못된 카테고리를 전달했을 때 커스텀 에러를 뜨게 하고싶은데 서버내부 오류가 발생함

해결
https://psychedelic-perigee-94e.notion.site/3-12caebccb8e481349527eacd61891cb8?pvs=4

💥 새로 알게된 점

고민 1. 카테고리별 조회 기능 어디서 처리해야하는가?

단순히 데이터를 가져오는 CRUD 기능 외에, 조회 조건이나 필터링 조건을 처리하는 것은 Service에서 담당하는 것이 일반적으로 더 효율적이다. Repository가 단순한 데이터 접근 계층으로 역할을 한정할 수 있게 하고, Service 계층에 비즈니스 로직을 모아두어 가독성과 확장성을 높이기 위한 설계 방식.

• Service 계층에 조회 조건(필터링, 정렬 등)을 관리 → 변경 사항이 생겨도 Service 계층만 수정
• Repository 계층은 단순히 findTop10ByOrderByCreatedAtDesc() 같은 기본 조회 쿼리를 제공
  → 이를 Service에서 호출하여 필요한 조건을 추가로 처리하는 것이 유지보수에 유리함!

💥 궁금한 점

궁금한 점. 잘못된 카테고리가 전달되었을 때 어디서 오류 처리를 해야하는가?

처음에는 서비스라고 생각했음 (이유 : 카테고리에 따라 글을 분류하는 역할을 서비스에서 처리하니까..?)
→ 결론 : 컨트롤러에서 처리함

💥 컨트롤러에서 카테고리 유효성을 검사하는 이유
입력된 요청 파라미터의 유효성 검사를 빠르게 처리 → 서비스 계층에 잘못된 값이 전달되지 않도록!
→ 이렇게 하면 서비스 계층에서 비즈니스 로직을 처리할 때는 이미 유효한 값이 전달되므로 코드가 보다 간결하고 오류가 줄어든다!

그런데 제 생각이 맞는지 모르겠어요 ㅠㅠ 😭

Screenshot 📸

To Reviewers 📢

너무 늦게 올려서 죄송해요 여러분 흑흑