dto 질문좀

[익명(39.120)]

jpa는 entity 가져와서 dto로 변환하던데 

mybatis쓰는데 dto로 db요청에 응답까지 dto 다 따로만들어서 쓰냐? mybatis인데 entity를 만들지는 않을거아니야?

[까먹음(112.214)]

ㅇㅇ mybatis에선 대부분 dto지. 요청 응답 반환할 때는 map을 쓰기도 함.

[익명(39.120)]

그러면 컨트롤러에서 requestdto로 바디데이터 받고 그거 바로 서비스에 꼿으면 종속성생기니까 서비스용dto만들어서 꼿고 서비스에서도 dao한테 바로꼿으면 종속성생기니까 또 만들고 디비조회하고 결과 dto만들고 또 컨트롤러까지 끌고와서 결과dto만들고 돌려줌? 원래 이렇게 dto많이만드냐?

[까먹음(112.214)]

ㅇㅇ 그렇게 안하면 어떻게 할거라고 생각한거야? 전부 dto로만 하는 게 꺼림직하면 값 받아오는 것들을 vo를 만들어. 솔까 vo조차도 setter없는 dto인 뿐인데 뭐.

[익명(39.120)]

그럼 현업에서는 그게 귀찮아서 종속성이니 뭐니 그냥 컨트롤러에서 dto바로 서비스에 꼿고 서비스에서 받은 dto 바로 dao에 꼿고 그러는거냐? 내가 본곳중에는 dto 필드 싹다 모아서 슈퍼dto에다가 생성자로 구별해서 쓰는곳도 보긴했는데 이게 이런 dto 레이어구분 같은거 검색해보면 다 jpa만 나와서 키워드좀 알려줄수있냐

[익명(223.38)]

si에선 그렇게 안 함 서비스에서도 도메인 마다 응답dto 요청dto 컨트롤러dto 서비스dto 이따구로 관리하는 기업은 대기업 아니고서야 없음

[익명(39.120)]

보통 si에서는 어케하냐? 나도 si 2년 했는데 슈퍼dto쓴데 빼고는 기억에 남는게없네

[프갤러 2(123.212)]

Si일때 api단 dto별도 sql용 vo따로 view용 vo따로임 Map같은건 사용 안함 카드번호나 엑셀 변환시 dto로 처리하는데 개 쓰레기 프로젝트나 map 쓰는거임

[익명(39.120)]

컨트롤러 -dto> 서비스 -dto1> dao -dto2>서비스-dto3>컨트롤러 -dto4>사용자 요렇게 갈때 어느 dto가 같은거고 어느 dto가 다른객체임?

[익명(39.120)]

난 원래 컨트롤러에 요청바디 매핑된 dto 바로 서비스넣고 그걸로 db검색해서 리턴되는객체 클라이언트한테 보내는식으로 많이 짰는데 유지보수관점에서 보면 완전 망한방법이네? 그나마 분리시킨건 요청 응답 객체 따로만든거 정도인데

[프갤러 1(112.161)]

mybatis 면 걍 쿼리에 다 때려 박겠다는건데 map 을 써라

[익명(39.120)]

map안쓴다면의 이야기다 dto를 쓴다면 레이어종속성까지 고려했을때 얼마나 dto를 세분화해서 써야될지 만약쓴다면 네이밍은 어떻게 구분할지 이런거 생각중 쓸데없긴한데 유지보수생각해서 공부해보게

[프갤러 1(112.161)]

jpa 안쓰고 SQL 종속적인 개발하겠다는건데 거긴 굳이 그런 고민까지 갈 필요가 없는 세상인거임 map 쓰되 깔끔하게 갈 수 있는 방법도 얼마든지 있다

[프갤러 1(112.161)]

결과적으로 그게 일만 늘리는 일이 될 거임 a테이블이랑 b테이블이랑 조인하고 안하고 c테이블이랑 조인한 경우 이딴거 다 객체로 만들거임? 이딴거 다 따지면 jpa같은 경우는 엔티티에서 긁어와서 도메인 객체에서 참조하니까 매핑 방식에서 대부분 해결되겠지

[익명(39.120)]

그럼 맵쓰는경우에는 dto대신에 다 map을 써? 근데 이러면 명세에 뭐가들어가는지 코드보면서 확인해야되지않냐?

[프갤러 1(112.161)]

그래서 si 는 코드보면서 확인하는거고 sm 는 si 개같이 했다고 욕하면서 일하는거 라고

[익명(39.120)]

그게 dto 레이어마다 만들면서 만드는것보다 편하다고? 아니지 솔직히 현업에서 레이어종속성을 생각안하고 걍 requestDto로 디비검색하고 responseDto로 api리턴때리는것보다 편해질수있는거냐?

[프갤러 1(112.161)]

거기서 문서 계속 만들라고 하면 만들던가 하면 되

[익명(223.38)]

댓삭햇는데 답글 달렷노ㅋㅋ; resultMap 은 entity 같은게 아니라 기존에 있던 dto를 중첩시켜서(Nested) 반환하는 역할을 함 예를들어 주문정보 dto가 있고 상품정보 dto가 있는데, 주문결과를 보여주려면 2 테이블을 조인해서 처리하잖아? 이걸 마바에서 dto로 맵핑하려면 주문결과 dto를 또 만드는 미친짓을 해야하는데, resultMap 기능을 쓰면 OrderDTO 속에 ItemDTO를 넣어서 flatten하게 반환할 수 있음

[프갤러 2(123.212)]

이런식으로 하믄 querydsl 쓸 이유가 없음 mybatis 나 쓰자구

[익명(223.38)]

쿼리dsl? 복잡한 동적 로직은 plsql 쓰는 si에서 그런건 사탄들린 라이브러리 취급임

[익명(39.120)]

근데 이렇게 중첩시켜서 반환하면 중첩된 dto에 null있거나 그러지않냐? fit하게 만들수있나?

[익명(39.120)]

흠 더 공부해봐야겠다 그래 고맙다

[익명(223.38)]

자꾸 댓삭에 한박자 늦게 달리네ㅋㅋ 일단 view 레이어에서 쓸 응답데이터에 필요한 컬럼은 sql 선에서 where 절로 not null 필터링 걸기 때문에 사용할 데이터가 null로 떨어질 일은 없음 만약 재사용할 쿼리라 where 조건을 맘대로 못 건다면 resultMap 내부에 콜렉션 프로퍼티 써서 null을 거르는 쿼리를 추가실행 해서 그 결과만 매핑할 수도 있음 나머지는 서비스 레이어에서 옵셔널로 감싼 값을 반환해서 최종적으로 null-safe하게 핸들링 하는거지 ㅇㅇ 근데 이건 si식 쿼리만능 개발이고 베스트 프렉티스는 아님