dto랑 map의 차이점은 프로파티에있다

[펙트폭격기인증..(wjdxoxowkd)]

맵은 프로파티명을 일일이 스트링으로 써줘야하니 취약점이 생기지 key부분을 이넘이로 바꾸면 dto처럼 쓸수야있음

[새싹볶음밥(dish90)]

아직도 이걸로 싸우냐 비지니스로직에 리터럴을 쳐박는게 말이되냐고 진짜

[펙트폭격기인증용(wjdxoxowkd)]

단점만 있는것은아니고 맵에서 굳이 장점을 말하자면 특정의경우에 특정의 프로파티가 필요한데 만약에 해당 dto에 없다면 맵의경우는 유동적으로 추가가능하다는 장점이있지 dto로해결할라면 해당 dto에서 추가해줘야하는데 특정경우에 쓰는게 아니라면 설계가 복잡해질뿐

[펙트폭격기인증용(wjdxoxowkd)]

일반적으로 쓰지도 않는 필드와 메소드가 dto에 들어가있다고 생각하면 이해하기 쉬울거다 맵의경우는 유동적으로 대처가능하지

[펙트폭격기인증용(wjdxoxowkd)]

특정경우 dtoA dtoB로 나눠서 하는방법도있지만 클래스파일이 늘고 결합도도 늘고 과연 효율적일까

[새싹볶음밥(dish90)]

근데 그 유동적으로 추가하는걸 팀 모두에게 공유하는데 드는 비용까지 고려해야지 혼자 짜더라도 문서화가 따로 필요하고. 아니면 내일의 나새끼와의 협업이 안되니까

[펙트폭격기인증용(wjdxoxowkd)]

유동적으로 추가하게될경우라는말은 가변프로파티라는말이지 설계적으로 이렇게만들어지는게 맞다고 본다 길게 멘테넌스가 진행되면 이런부분은 반드시 필요하니까 다형성으로 구현해서 서브를 나누든가 빌더가 최선이겠지 맵의 장점과 비슷하게 활용할라면 빌더로 구현하는게 최선이긴해

[펙트폭격기인증용(wjdxoxowkd)]

결론적으로 dto의 장점과 map의 장점을 같이살려서 설계를해야한다 서로 각 장점이 다르니 ㅇㅇ

[새싹볶음밥(dish90)]

그런 경우엔 맵도 고려할수 있겠다 DTO를 쓰는게 모든상황에서 정답은 아니니까 근데 문제는 가변프로퍼티가 아닌데도 키를 리터럴 스트링으로 넣고 맵을 썼을때지

[펙트폭격기인증용(wjdxoxowkd)]

리터럴로 쓰게될경우 타입이 안전하지않을가능성과 유저가 실수할 가능성이 높아지지 dto로 사용하면 이런부분을 유저가 생각하지않아두 되는 장점은 있지만 수정이 필요하게될경우 해당 dto를 이용하는 클래스들의 전체적인 영향을 고려해서 짜야함

[익명(59.24)]

요약: dto 쓰라고 ㅂㅅ들아