SISC-BE-부모게시판 목록 조회#123
Hidden character warning
Conversation
Walkthrough새로운 API 엔드포인트 GET Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant Controller as BoardController
participant Service as PostService
participant Repo as BoardRepository
Client->>Controller: GET /api/board/parents (with auth)
activate Controller
Controller->>Service: getParentBoards()
activate Service
Service->>Repo: findAllByParentBoardIsNull()
activate Repo
Repo-->>Service: List<Board> (parentBoard == null)
deactivate Repo
Note over Service: Map each Board -> BoardResponse.of()
Service-->>Controller: List<BoardResponse>
deactivate Service
Controller-->>Client: 200 OK (List<BoardResponse>)
deactivate Controller
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30분
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
backend/src/main/java/org/sejongisc/backend/board/repository/BoardRepository.java (1)
3-10: 최상위 게시판 조회 메서드 정의 적절함
findAllByParentBoardIsNull()네이밍이 명확하고 Spring Data JPA 규칙에 잘 맞습니다. 최상위(부모 없음) 게시판 조회 용도로 충분히 직관적입니다.
프론트에서 일관된 정렬(예: 생성일 오름차순, 이름순 등)을 요구한다면,findAllByParentBoardIsNullOrderByCreatedDateAsc()같은 메서드를 추가로 두는 것도 장기적으로는 고려해볼 만합니다.backend/src/main/java/org/sejongisc/backend/board/service/PostServiceImpl.java (1)
298-307: 부모 게시판 조회 로직이 단순하고 역할에 충실함
findAllByParentBoardIsNull()으로 엔티티를 조회하고,BoardResponse.of()로 DTO 매핑하는 흐름이 간결하고 이해하기 쉽습니다.@Transactional(readOnly = true)도입도 적절합니다.
다만, 화면에서 특정 정렬 순서를 기대한다면 이 단계에서 정렬(예: 생성일/이름 기준)을 보장하도록 Repository 메서드 또는 Stream 정렬을 추가하는 것도 고려해볼 수 있습니다.backend/src/main/java/org/sejongisc/backend/board/dto/BoardResponse.java (1)
1-37: 매핑 로직은 명확하지만User엔티티 직접 노출은 장기적으로 리스크
BoardResponse.of(Board board)에서boardId,boardName,createdBy,parentBoardId를 빌더로 매핑하는 부분은 간결하고 NPE 처리도 잘 되어 있습니다.다만
createdBy타입을User엔티티로 두면:
User안에 비밀번호 해시, 이메일 등 민감 정보가 포함되어 있을 경우 그대로 API 응답에 노출될 수 있고,- 양방향 연관관계가 걸려 있다면 직렬화 시 순환 참조나 과도한 JSON 페이로드가 생길 수 있습니다.
새 DTO 도입 부담이 있다면 당장은 유지하되, 중장기적으로는 예를 들어
UserSummaryResponse(userId, nickname 정도만 포함) 같은 별도 DTO로 축소하여 응답하는 구조로 리팩터링하는 것을 추천합니다.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
backend/src/main/java/org/sejongisc/backend/board/controller/BoardController.java(2 hunks)backend/src/main/java/org/sejongisc/backend/board/dto/BoardResponse.java(1 hunks)backend/src/main/java/org/sejongisc/backend/board/repository/BoardRepository.java(1 hunks)backend/src/main/java/org/sejongisc/backend/board/service/PostService.java(2 hunks)backend/src/main/java/org/sejongisc/backend/board/service/PostServiceImpl.java(3 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
backend/src/main/java/org/sejongisc/backend/board/controller/BoardController.java (1)
backend/src/main/java/org/sejongisc/backend/common/auth/springsecurity/CustomUserDetailsService.java (1)
RequiredArgsConstructor(16-38)
🔇 Additional comments (2)
backend/src/main/java/org/sejongisc/backend/board/service/PostService.java (1)
3-7: Service 인터페이스에 부모 게시판 조회 기능이 자연스럽게 확장됨
List<BoardResponse> getParentBoards()추가로 부모 게시판 조회 책임이 PostService에 잘 녹아들었습니다. DTO를 반환하도록 설계한 점도 컨트롤러와의 경계를 명확히 해 줍니다.Also applies to: 34-35
backend/src/main/java/org/sejongisc/backend/board/service/PostServiceImpl.java (1)
8-8:createBoard오버라이드 명시로 구현 명확성 향상인터페이스
PostService#createBoard에 대응하는 구현 메서드에@Override를 명시해 둔 것은 유지보수 시 시그니처 변경 누락을 방지하는 데 도움이 됩니다. 로직 자체는 기존 구현을 잘 유지하고 있어 문제 없습니다.Also applies to: 268-296
Summary by CodeRabbit