예를 들어서 게시물의 제목, 조회수만 필요한 api 요청이 있을 때
FindById해서 dto로 변환해주면
Select *… 쿼리로 나가는 거잖아?
근데 필요없는 컬럼까지 조회하는 경우 성능이 느려진다고 하던데
1. 조회 요청은 모두 프로젝션을 사용해서 조회하는 거야?
2. 그렇다면 3 tier 아키텍처라고 했을 때 repository부터 controller까지 하나의 dto로 쭉 반환해? 아니면 거기서도 계층별로 dto를 변환해?
고견 부탁
1번은 필요한 칼럼만 긁어와야징.. 계층마다 dto를 다르게 사용하면 좋지않나? 계층마다 필요로하는 dto가 살짝식 다를텐데..물론 학부따리는 .하나의 dto써봄 곧 고수님들 의견 내러올듯 - dc App
하나의 dto로 쭉 올릴거면 사실 계층을 나누는 의미가 없지 않나라는 생각이 들어서 질문함 매번 필요한 컬럼만 다룬다는 것이 나에겐 프론트에서 화면을 그릴 때 필요한 데이터만 모아주는 것처럼 느껴져서 보여지는 부분은 언제든지 변할 수 있을텐데 그렇다면 그 때마다 모든 계층에서는 영향을 받게될거고 그렇게 설계하는것이 옳은지 궁금해서 질문 남김
엥 근데 생각해보니 계층마다 dto를 다 불러옴? - dc App
계층별로 다 불러온다는게 무슨 말임?
아 예전 프젝할때 dto 계층마다 필요하면 다 만들어낫네 유연성때문이네 - dc App
난 쿼리 한번으로 필요한 데이터를 다 클라이언트에 보낼수있으면 dto하나만 쓰고 n번 이상 쿼리가 나가야되면 dto 여러개로 레포에서 리턴받고 서비스에서 합쳤음 - dc App
계층 나눈건 각 클래스마다 하나의 역할을 가지게 하려고 나눈게 큼. 컨트롤러는 단순히 요청받고, 서비스는 실제 비즈니스 로직 및 트랜잭션 적용하고, 레포는 쿼리 날리고 등등 이걸 한군데에 몰아넣으면 다른 사람이 코드볼때 지옥이야 - dc App
필요한 데이터만 조회를 하는건 내가 생각한 것처럼 프론트에게 필요한 정보만 줘야하기 때문이야? 아니면 다른 예시가 있으면 알려줄 수 있을까
ㅇㅇ 난 너처럼 생각하긴 해 - dc App
답변 고마워~~
1. 일반적으로는 그렇지 2. 계층별로 반환하지
근데 프로젝션 쓰는게 꼭 성능만을 위한건 아님 조인때문에 쓰는 경우도 많음 이른 최적화를 하면 프로젝션 모델 파편화돼서 관리 힘들다 성능은 항상 필요한 만큼만
만약 게시글 제목, 조회수, 카테고리가 필요하게끔 변경해야하는 상황이 오면 모든 계층에서 dto를 수정해야하잖아 만약 entity로 넘기고 컨트롤러 dto에서 필요한 정보만 뽑아서 쓴다고 하면 컨트롤러쪽 코드만 수정하면 될 거 같은데 그럼에도 불구하고 1번으로 하는 이유는 성능을 먼저 고려해야하기 때문인거야??
대댓을 못봤나?
댓글을 작성하던 중에 대댓이 달려서 못보고 남겼네 미안해 성능 최적화가 필요한 상황이 아니라면 내 대댓처럼 코드를 작성해도 무방한거야?
물론이지 정답은 없고 니 방식이 잘못된 것도 아님 근데 컨트롤러 레이어로 엔티티 반출하면 안되는거 알제?
아아 응 그래서 컨트롤러 쪽으로 반환할 때는 dto로 한번 더 변환해서 넘겨줘야겠다!! 답변 고마워