님 맘대로 하면됨
대가리 좆 빠개진 새끼들은 dto vo 안만들고 map에 다 스까서 만들었다가 디버깅 안되고 머 그런것도 비일비재함 ㅋㅋ
익명(118.40)2022-02-25 00:37
답글
map...
익명(175.223)2022-02-25 00:37
답글
ㅎㅎ.. 개선프로젝트하다가 dto랑 vo 개좆같이 쓸데없이 많이 만들어놔서 일괄로 싹다 map으로 바꾼 적 있는데
익명(118.36)2022-02-25 00:38
답글
map 써도 되긴 하는데 ㅈ같이 쓰는 사람들 있음
익명(118.40)2022-02-25 00:38
답글
뭘 쓰든 ㅈ같이 쓰는 사람이 있긴한데 주로 map쓰는 사람들이 ㅈ같은 경우가 많지
익명(118.36)2022-02-25 00:39
답글
가변적으로 여러 db 데이터 스까 가져와야 하거나
진짜 조금 가져올건데 vo 일일히 만들면 쌉 비능률이라 이럴땐 map 써도 괜찮지만
모든 경우에 map을 쓰는건 좀 아닌거같음
익명(118.40)2022-02-25 00:40
답글
소스가 많다는 이유로 다 지우고 맵으로 바꾼거면 오히려 퇴보 아닌가. 맵 장점이 하나하나 안만들어도 되는건데 이미 만들어진걸 지운거면 진짜 헛짓거리 두번한건데
익명(118.222)2022-02-25 00:41
답글
vo dto도 상황 안맞게 ㅈ같이 짜는 애들도 있어서 다 지워버린것 같음
예를들면 테이블 2개 조인해서 데이터 가져오는건데
이런 경우에 능지 깨진 애들은 리턴값 어케 받아올까? 하다가
2개 테이블 스까진 vo를 또 만듦 ㅋㅋ
익명(118.40)2022-02-25 00:42
답글
그런 경우는 어케 함? 나도 능지 모자란 놈이라 그렇게 해야 하지 않나 생각했는데 왜 안좋은 방법이야?
익명(118.222)2022-02-25 00:46
답글
단적으로 테이블 crud를 위한 vo, dto가 따로 있고 네이밍 안맞고 수정한 것에 따라 suffix로 Old, V1, V2 붙은 소스도 있고 prefix로 old_ 붙고
Origin of 붙은 것도 있고 아주 상황이 그지 같았음
익명(118.36)2022-02-25 00:47
답글
db 조인해서 데이터 가져오면가져올 수 있는 데이터의 경우의 수가 존나 많은데이때 vo나 dto로 해결하는 방법은 두가지임위 글쓴이 상황처럼 조회 해오는 데이터 성격따라 vo, dto를 무한히 새로 만드는 방법이고두번째는 하나의 dto에 여러 엔티티 다 따려박고 조회하는거임근데 그렇게 관리하면 유지보수하기 ㅈ같아짐그래서 db랑 매칭해서 vo dto 만들고이 vo dto 로 쿼리 결과값 담아오지 못하는 경우만 map을 통해 받아온 다음에다시 그걸 vo나 dto에 나눠 담아주는 방법으로 좀 더 예측 가능한 데이터 흐름을 만들 수 있음
익명(118.40)2022-02-25 00:52
답글
ㅅㅂ 글이 많아서 줄바꿈 다 씹힘 알아서 해석하셈
익명(118.40)2022-02-25 00:53
답글
나는 무한히 만드는걸 선호했는데 그 이유가 1:1로 dto가 매칭되는 경우를 거의 못봐서 그랬거든 하나 이상 조인이 들어가는 경우가 대부분이라. 이걸 조인된 테이블만큼의 dto를 생성해서 받아야 한다는 말인가? 개발할때는 그게 편할 것 같긴 한데 메모리 측면에서 낭비가 생기진 않나
익명(118.222)2022-02-25 00:58
답글
뭔 메모리를 따지고 있나요? C++로 curd 구현하면 메모리 따지는게 맞죠
근데 JAVA나 그외 언어로 개발할땐 메모리 관리 가상머신이 알아서 해주니
이땐 시간복잡도랑, 코드 가독성, 유지보수성 이 3가지를 챙기는게 더 나을거라 생각됩니다.
익명(118.40)2022-02-25 01:01
답글
아무튼 감사 내가 생각지도 못했던 부분이라
익명(118.222)2022-02-25 01:03
답글
조인된 조건만큼 dto 만드는게 비효율이라는 거구요
그냥 처음에 테이블 갯수가 10개면 vo 10개, 100개면 100개 매칭해서 일단 만들어 놓고
나중에 dto 하나에 vo들을 집어넣는 방식 까지는 괜찮을거라 생각되요
근데 쿼리 조건에 따라 dto가 늘어나는건 엄청 유지보수가 어려울거같읍니다.
익명(118.40)2022-02-25 01:04
답글
경험상 db가 바뀌지만 않으면 유지보수는 편하더라구. 거의 고유 dto인 느낌이라 기능 하나 수정하면 걔만 딱 바꾸면 돼서
익명(118.222)2022-02-25 01:08
거의같음
익명(175.223)2022-02-25 00:37
VO나 DTO나 쓰이는 건 비슷하고 굳이 차이를 뽑자면 VO는 참조 객체(new로 만드는 object)말고 순수 단일 값으로 취급될 수 있는 애들(int라던지, string이라던지)이 들어있는 걸 말하지
님 맘대로 하면됨 대가리 좆 빠개진 새끼들은 dto vo 안만들고 map에 다 스까서 만들었다가 디버깅 안되고 머 그런것도 비일비재함 ㅋㅋ
map...
ㅎㅎ.. 개선프로젝트하다가 dto랑 vo 개좆같이 쓸데없이 많이 만들어놔서 일괄로 싹다 map으로 바꾼 적 있는데
map 써도 되긴 하는데 ㅈ같이 쓰는 사람들 있음
뭘 쓰든 ㅈ같이 쓰는 사람이 있긴한데 주로 map쓰는 사람들이 ㅈ같은 경우가 많지
가변적으로 여러 db 데이터 스까 가져와야 하거나 진짜 조금 가져올건데 vo 일일히 만들면 쌉 비능률이라 이럴땐 map 써도 괜찮지만 모든 경우에 map을 쓰는건 좀 아닌거같음
소스가 많다는 이유로 다 지우고 맵으로 바꾼거면 오히려 퇴보 아닌가. 맵 장점이 하나하나 안만들어도 되는건데 이미 만들어진걸 지운거면 진짜 헛짓거리 두번한건데
vo dto도 상황 안맞게 ㅈ같이 짜는 애들도 있어서 다 지워버린것 같음 예를들면 테이블 2개 조인해서 데이터 가져오는건데 이런 경우에 능지 깨진 애들은 리턴값 어케 받아올까? 하다가 2개 테이블 스까진 vo를 또 만듦 ㅋㅋ
그런 경우는 어케 함? 나도 능지 모자란 놈이라 그렇게 해야 하지 않나 생각했는데 왜 안좋은 방법이야?
단적으로 테이블 crud를 위한 vo, dto가 따로 있고 네이밍 안맞고 수정한 것에 따라 suffix로 Old, V1, V2 붙은 소스도 있고 prefix로 old_ 붙고 Origin of 붙은 것도 있고 아주 상황이 그지 같았음
db 조인해서 데이터 가져오면가져올 수 있는 데이터의 경우의 수가 존나 많은데이때 vo나 dto로 해결하는 방법은 두가지임위 글쓴이 상황처럼 조회 해오는 데이터 성격따라 vo, dto를 무한히 새로 만드는 방법이고두번째는 하나의 dto에 여러 엔티티 다 따려박고 조회하는거임근데 그렇게 관리하면 유지보수하기 ㅈ같아짐그래서 db랑 매칭해서 vo dto 만들고이 vo dto 로 쿼리 결과값 담아오지 못하는 경우만 map을 통해 받아온 다음에다시 그걸 vo나 dto에 나눠 담아주는 방법으로 좀 더 예측 가능한 데이터 흐름을 만들 수 있음
ㅅㅂ 글이 많아서 줄바꿈 다 씹힘 알아서 해석하셈
나는 무한히 만드는걸 선호했는데 그 이유가 1:1로 dto가 매칭되는 경우를 거의 못봐서 그랬거든 하나 이상 조인이 들어가는 경우가 대부분이라. 이걸 조인된 테이블만큼의 dto를 생성해서 받아야 한다는 말인가? 개발할때는 그게 편할 것 같긴 한데 메모리 측면에서 낭비가 생기진 않나
뭔 메모리를 따지고 있나요? C++로 curd 구현하면 메모리 따지는게 맞죠 근데 JAVA나 그외 언어로 개발할땐 메모리 관리 가상머신이 알아서 해주니 이땐 시간복잡도랑, 코드 가독성, 유지보수성 이 3가지를 챙기는게 더 나을거라 생각됩니다.
아무튼 감사 내가 생각지도 못했던 부분이라
조인된 조건만큼 dto 만드는게 비효율이라는 거구요 그냥 처음에 테이블 갯수가 10개면 vo 10개, 100개면 100개 매칭해서 일단 만들어 놓고 나중에 dto 하나에 vo들을 집어넣는 방식 까지는 괜찮을거라 생각되요 근데 쿼리 조건에 따라 dto가 늘어나는건 엄청 유지보수가 어려울거같읍니다.
경험상 db가 바뀌지만 않으면 유지보수는 편하더라구. 거의 고유 dto인 느낌이라 기능 하나 수정하면 걔만 딱 바꾸면 돼서
거의같음
VO나 DTO나 쓰이는 건 비슷하고 굳이 차이를 뽑자면 VO는 참조 객체(new로 만드는 object)말고 순수 단일 값으로 취급될 수 있는 애들(int라던지, string이라던지)이 들어있는 걸 말하지
좀 더 자세히 알고 싶으면 마틴아저씨가 쓴 엔터프라이즈 아키텍처 패턴에 나와있으니 참고
고마웡