티스토리 뷰
최근 개인 토이프로젝트를 진행하다 보면,
사실상 코드를 짜다 모르는 부분은 어딘가에서 검색한 결과를 잘 붙여넣어 잘 수정하면 굴러간다는 사실을 개발공부 근 1년만에 알아차렸다.
지금에서 시간을 잡아먹는 부분은 이 메서드가 어디있어야 할까. 이놈이 저기에서 동작하는게 과연 맞는가. 하는 문제로 허무하게 시간을 보낼때가 있다.
게시판을 만들며 댓글구현은 금방하는 일이겠거니 하며 진행하다가 뜬금없는 고민에 빠져 책(클린코드)을 구매하고
객체지향의 원칙까지 다시한번 주의깊게 본 경험이 생겨 올려본다.
댓글
@Data
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class ReplyDTO {
/**
* 댓글 pk
*/
private Long replyNo;
/**
* 댓글 내용
*/
@Min(value = 3)
private String replyContent;
/**
* 게시글 번호 fk
*/
private Long boardNo;
/**
* 댓글 생성일자
*/
private String replyRegDate;
}
참으로 특별한거 없는 댓글 DTO이다.
<!-- 댓글 조회 -->
<select id="getReply" resultType="ReplyDTO">
SELECT
r.reply_content,
r.reply_reg_date
FROM
reply r
WHERE
board_no = #{boardNo}
ORDER BY
reply_reg_date DESC;
</select>
@Mapper
public interface ReplyRepository {
/**
* 댓글 조회
* @param boardNo
* @return
*/
List<ReplyDTO> getReply(Long boardNo);
}
게시판 번호를 통해 댓글리스트를 반환하는 과정이 담긴 xml파일과 ReplyRepository이고 고민은 여기서 시작된다.
내가 만든 List<ReplyDTO>는 과연 어디로 가야하나?
평소대로의 생각이라면
boardService가 있다는 가정하에
//BoardDTO
public class BoardDTO {
/**
* pk 게시글
*/
private Long boardNo;
/**
* 게시글 제목
*/
private String boardTitle;
/**
* 게시글 내용
*/
private String boardContent;
/**
* 게시글 작성자
*/
private String boardWriter;
/**
* 댓글 리스트
*/
private List<ReplyDTO> replyList;
}
//BoardService
/**
* 자유 게시판 특정게시글 조회
* @param boardNo
* @return
*/
public BoardDTO getFreeViewArticle(Long boardNo) {
//게시글 가져옴
BoardDTO dto = freeRepository.getFreeViewArticle(boardNo);
//댓글리스트
List<ReplyDTO> replyList = replyRepository.getReply(boardNo);
dto.setReplyList(replyList);
return dto;
}
(게시판의 특정게시글을 조회하는 getFreeViewArticle 메서드가 있다)
아마 평소와 같은 방식으로 만들었다면 이런 과정이 되었을 것이다.
상세조회를 했을시 게시글안에 댓글리스트를 집어넣어 반환된다면 아마
[{
boardTitle: 제목,
boardWriter: Mo-Greene,
boardContent: 내용,
replyList : {
replyContent: 댓글내용,
replyRegDate: 댓글생성날짜
}
}]
이런 객체를 보내게 될것이다.
뭐 나쁘지 않다. 이게 맞는 방법일 수도 있다고 생각하지만 혹여나 하는 생각을 하게 되었다.
만약 댓글의 요청사항이 바뀐다면?
여러가지가 있을 수 있다고 본다. 게시판이 늘면서 댓글리스트를 다른곳에서도 사용한다던가?
replyRegDate를 포맷팅하여 보낼 수도 있고(프론트의 영역이라고 생각하지만)
쉽게 생각은 안나지만 어떤 기상천외한 요구가 생길지는 아무도 모른다.
그럴때마다 댓글의 구현을 "getFreeViewArticle"이란 메서드 안에서 실행한다면
이 메서드는 더 이상 게시글 상세조회의 역할이 아닌 그 이상의 역할을 하게 된다는 생각을 하게되었다.
단일 책임 원칙 (SRP: Single Responsibility Principle)
하나의 클래스에는 하나의 책임을 가진다.
getFreeViewArticle는 게시글을 가져오는 책임과 댓글을 가져오는 2개의 책임을 갖게 되었다.
만약 이 메서드를 수정하는 상황이 온다면 List<ReplyDTO> 에서 어떤 에러가 나올지 매번 생각하며 코드를 짜야한다.
그래서 결론은?
BoardController
/**
* 자유게시판 특정게시글 조회
* @param boardNo
* @param model
* @return
*/
@GetMapping("/free/{boardNo}")
public String getFreeView(@PathVariable Long boardNo, Model model) {
BoardDTO dto = boardService.getFreeViewArticle(boardNo);
List<ReplyDTO> replyDtoList = replyService.getReply(boardNo);
model.addAttribute("dto", dto);
model.addAttribute("replyDto", replyDtoList);
return "board/free/freeView";
}
간단히 분리해서 model에 각각의 값으로 보내주었다.
만약에 boardService에서 요구사항이 생겨 고친다면 저부분만 고치면 될것이고
replyService의 요구사항이 생기면 그 부분만 고치면 다른것을 건드릴 필요없이 해결이 될 것이다.
'Backend > SpringBoot' 카테고리의 다른 글
SpringBoot 파라미터 달고다니기 (0) | 2023.04.26 |
---|---|
SpringSecurity 없이 SpringBoot 자동로그인 구현 (0) | 2023.04.24 |
SpringBoot 파일 다운로드 (0) | 2023.04.10 |
로그인 전 요청화면 유지하기 (0) | 2023.04.09 |
SpringBoot 다중 파일 업로드 구현 (0) | 2023.04.08 |
- script setup
- 프로그래머스
- Vue.js3
- 맥 error
- 리눅스마스터2급
- SpringSecurity
- 함께모으기
- springboot
- 짝지어제거하기
- 책리뷰
- 객체지향의 사실과 오해
- 토스페이먼츠
- 객체지향
- java 플레이그라운드
- 알고리즘
- 객체 지도
- 정수형으로 변환
- it책 리뷰
- vuex
- 스프링부트
- 한권으로끝내기리눅스마스터2급
- CompositionAPI
- mybatis구현
- JWT
- LEVEL2
- 타임리프
- 다음 큰 숫자
- pinia
- for
- vue.js
- Total
- Today
- Yesterday