작성
·
194
0
수업 거의 다 듣고 포트폴리오 만드는 중에 질문드립니다.
fetchBoards로 게시판을 불러올때 리턴 객체명을 어떻게 해야할지 모르겠습니다. 예를 들어, board[], paging 값이 두개 리턴이 된다고 했을때 dto폴더에 select-board.output.ts 객체 파일을 만들어주면 될까요?
아니면 board[], paging 형태로 내보내는것은 나쁜 방식일까요? 웬만하면 프론트가 아니라 백에서 처리해서 내보내려고 합니다.
이런식으로 폴더 구분이랑 파일 이름 짓기가 모호한 경우가 많은데 여기에 초점을 맞춘다고 시간을 허비하지말고 구분만 잘해놓는게 좋을까요?
답변 2
1
안녕하세요! MJ님!
우선 답변이 늦어 죄송하다는 사과의 말씀 드립니다!
바로 답변을 드려볼게요!
board[], paging 값이 두개 리턴이 된다고 했을때 dto폴더에 select-board.output.ts 객체 파일을 만들어주면 될까요?
=> .output.ts 형태로 파일을 만들어 보내는 것이 가장 일반적인 방식으로 추천드립니다!^^
다만, select-board보다는, 해당 output의 이름을 따로 작명해 주시는 것이 좋을 것 같아요!
select-board 말고, 다른 서비스에서 재사용 될수도있고, 다른 API를 조회하는데 함께 받아오는 다양한 경우들이 생길 수 있기 때문이랍니다!
아니면 board[], paging 형태로 내보내는것은 나쁜 방식일까요? 웬만하면 프론트가 아니라 백에서 처리해서 내보내려고 합니다.
=> 상황에 따라 달라질 수 있습니다.
하지만, 유지보수 측면을 고려하시어, 반드시 필요한 경우에만 새로운 dto 를 만들어 보시는 것이 좋을 것 같아요! 해당 유지보수는 백엔드 측면도 있으나, 프론트엔드에서 해당 결과물에 대한 client-cache의 유지보수 측면도 함께 논의되어야 하는 부분이기 때문이랍니다!
이런식으로 폴더 구분이랑 파일 이름 짓기가 모호한 경우가 많은데 여기에 초점을 맞춘다고 시간을 허비하지말고 구분만 잘해놓는게 좋을까요?
=> 실무 프로젝트라면, 실무 시스템에 맞추어 빠르게 진행하는 것이 좋을 것 같아요!
그러나, 팀원들을 위해 프로젝트를 설계하는 상황, 또는 공부하는 상황이라면 시간 허비라기보단 반드시 필요한 과정인 것 같아요!^^ 잘 하고 계신 것 같으니 충분히 고민해 보세요!
추가로)
만약, paging이 현재 게시물의 몇 페이지인지를 나타내는 것이라면, 이것은 프론트엔드에서 "3페이지 줘!", "4페이지 줘!" 형태로 만들어 보는 것이 유지보수 측면에서 유리할 것 같아요!
혹은 다른 의미의 paging 변수라면, 크게 2가지를 고민해 보셔야 합니다.
paging만 함께 보내는 것인지? 아니면, 추후에 paging, qqq, zzz 등이 더 추가될 수 있는 것인지?
만약, 절대 추가될 일 없다면 명시적으로 BoardWithPaging 으로 하는 것도 괜찮으나,
일반적으로는 확장되기 마련이므로 이런 내용을 포함하는 OOO으로 만드는게 좋을 것 같아요. BoardWithSystem 과 같은 형태로 말이에요!^^
0
안녕하세요, 인프런 AI 인턴입니다.
MJ님, 프로젝트의 파일명과 구조를 짓는 것은 개발 과정에서 아주 중요한 부분입니다. 특히 여러 데이터를 반환할 때는 어떻게 구조를 짜고 이름을 짓느냐가 유지보수와 가독성에 큰 영향을 미치죠.
fetchBoards
의 경우에는 게시판(board) 데이터와 페이징(paging) 정보를 함께 반환하고자 하신다면, 명확한 구조의 DTO(Data Transfer Object)를 생성하는 것이 좋습니다. select-board.output.ts
라는 이름도 괜찮으나, 반환되는 객체의 구성을 좀 더 명확히 드러내는 이름을 사용하시는 것도 좋습니다. 예를 들어, boardsResponse.dto.ts
라고 하면 게시판 데이터와 관련된 응답이라는 것을 좀 더 분명하게 알 수 있겠죠.
DTO 내부에서는 boards
및 paging
정보를 명시적으로 가지고 있는 구조로 만드는 것이 좋습니다. 예를 들어 다음과 같이 말이죠:
class BoardsResponseDto {
boards: Board[];
paging: PagingInfo;
}
객체와 배열, 그리고 추가적인 정보를 함께 내보내는 것은 나쁜 방식이 아닙니다. 오히려 프론트엔드에서 필요한 정보를 한 번의 요청으로 충분히 제공받을 수 있어 효율적인 대응이 가능해지죠. 중요한 것은 이렇게 반환하는 구조가 일관적이고 문서화되어 있어야 한다는 점입니다.
폴더 구분 및 파일 이름 짓기가 모호한 경우에는 구체적이고 일관된 규칙을 설정하는 것이 중요합니다. 처음에는 시간이 걸리더라도, 이후에 프로젝트가 커졌을 때 더 빠르고 정확하게 작업할 수 있는 기반을 마련하는 것이기 때문에 전혀 시간 낭비가 아닙니다. 경험을 통해 자신만의 베스트 프랙티스를 찾아가시기 바랍니다.
이것저것 알아보다가 예제가 없어서 질문을 드렸는데 충분히 답변을 받은것 같아 감사드립니다. 늦게 보긴했지만 많은 도움이 됐습니다~