vo대신 map사용하면 어떤가요?

Question

지금까지 그냥 해오던데로 vo를 썼습니다.별 생각 없이 당연하게 써왔는데요.이번 프로젝트에서는 고객사 실무 담당자가 매번 vo를 만드느니 차라리 map를 쓰면 어떻겠느냐고 묻는데 vo대신 map를 사용하는데에 대하여 깊이 생각해보질 않아 선듯 대답을 못하고 생각해 보겠다 하고 말았는데요.혹시vo 대신 map를 사용하면 특별히 예측되는 문제는 뭐가 있을까요?

살다보니개발자 · Answer

프로젝트에서 vo class 가 map 이랑 별로 차이없으면 map 쓰든 vo 쓰든 같을 것 같네요하지만 vo 클래스가 상속이나 인터페이스 구현하고 있으면 vo 쓰는ㄱ 좋을 것 같습니

준호 · Answer

어디서 이 값을 셋팅하고 가져다 쓰는지 추적이 매우 어려워집니다.

N+! · Answer

객체지향적으로 구현하지 않으면 vo나 map이나 동일하죠

엡실론 · Answer

VO란 결국 어떤 값들을 서로 주고 받을지, 어떤 형식으로 주고 받을지 서로 합의 된 결과물입니다. 그걸 코드로 써서 타입 안전성을 추구하느냐 아니냐의 문제죠. map으로는 무슨 필드가 있는지, 어떤 이름인지, 어떤 타입인지 아무것도 보장할 수가 없습니다.예를 들어서 name 필드가 있어야 하는데, 한쪽에서 오타로 nmae이라고 썼다고 해봅시다. 실제로 실행하기 전까지는 전혀 알 수가 없습니다. 필드 이름을 상수를 선언해서 썼다면 그나마 다행이지만, 곳곳에 이름을 직접 썼다면? 언제 어디서 문제가 나도 이상하지가 않죠.또, 한쪽은 반드시 name 필드가 있을 거라고 생각하고, 다른쪽은 없을 수도 있다라고 서로 오해한다면? VO로는 이런 상황을 원천 차단할 수 있지만, map으로는 힘들죠.map을 쓰든, VO를 쓰든 상호간의 합의가 필요할텐데, 거기에 조금 더 노력을 더해서 VO를 만드는 편이 장기적으로는 훨씬 좋습니다.물론 경우에 따라선 VO를 만드는게 힘들고, map을 써야 할 수도 있습니다. 예를 들면, 데이터를 보내는 쪽 시스템은 범용적이라서 상대에 따라 다양한 데이터를 보낼 수 있어서 VO로 표현하긴 힘들지만, 받는 쪽이 정해지면 항상 일정한 데이터 형식을 보장 하는 경우가 있을 수 있습니다. 이 경우 받는 쪽에서는 항상 일정한 형식을 기대할 수 있겠죠. 이때는 주고 받을 땐 map을 쓰더라도 받는 쪽에선 vo로 변환해서 처리하는게 낫습니다.

집킨 · Answer

그냥 vo쓰세요

장독깨기 · Answer

저 같은 경우 전부 Map 으로 처리 합니다. 그리고, 외주 일 경우는 수행사 측에 확인을 먼저 하구요, 잘 못 하면 새 되는 수가 있으니. ㅎ근데, 고객사에서 저러는건 또 처음 보는데요, 좀 신기하긴 하네요.뭐 암튼, Map 사용해서 문제 된 적은 없습니다. :)

NPE · Answer

Type-safe 하지 않습니다

방황하는젊은이 · Answer

저 같은경우엔 Insert, Update 같은경우에는 DTO를 선호했고, Select 에서는 Map을 선호했으나 최근엔 Frontend 와 Backend 가 서로 완전히 분리되면서 (Backend Spring, Frontend NodeJS + VueJS or React) API 생성시 Swagger 때문에라도 DTO 와 VO 를 합쳐 Domain 이라는 대표 클래스안에 다양한 DTO 와 VO를 만듭니다.

oioioi · Answer

대부분 vo, dto를 만들지 map으로 처리 안해요

カワウソ · Answer

저는 Map으로 모든 것을 표현하는 건 좋지 않다 생각하지만 고객사의 요구사항을 들어주는게 맞지 않나요.뭐 개발자 입장에서 생각하면 사람의 실수는 어디에서든지 존재하기 때문에 NullPointerException이나 빈 문자열 등의 방어코드를 빼먹을 가능성이 높지 않을까 싶습니다. 뭐 별도의 클래스를 만들어도 동일한 실수는 남발하기에 무슨 차이가 있냐라고 물으면 할 말은 없겠어요.

지붕뚫고높이차 · Answer

다들 VO 사용을 권장하는 것 같네요. 관습이 된 VO 쓰지 말라고 할 수 없으니 단점을 나열해 봅니다. 모르고 쓰면 불편함이 익숙해지지만 알고 쓰면 불편함을 해결 할 수 있거든요. 오타를 방지할 수 있기 때문에 VO 를 사용한다고 하지만 xml, jsp 등 실행에 필요한 메타, 구문 오타는 알 수 없습니다. 특히 카멜표현법과 축약어로 결합된 이름은 실행시점에 오류가 발생하기 때문에 원인 찾기도 어렵습니다.VO 는 객체지향적이지 않습니다. 데이터만 있고 실행시점이 아닌 컴파일 시점에 객체가 결정되기 때문입니다. 쉽게 이야기 해서 VO 를 사용하는 코드는 항상 컴파일을 한 뒤 배포를 해야하는 절차지향적인 코드가 됩니다.간혹 VO 의 get, set 메소드에 검증기능 데이터 가공등의 코드를 적용하기도 하는데 이는 VO 를 사용하는 코드와 역할이 겹치게 되어 모호해지는 코드가 됩니다. 또한 객체지향지적이지 않기 때문에 상속 또는 인터페이스로 VO 를 구성한다 하더라도 컴파일이 필요한 절차지향적인 코드가 됩니다.VO 로 비즈니스 로직을 확인할 수 없습니다. VO 는 데이터를 담는 그릇의 역할이고 비즈니스 로직은 그릇에 담긴 데이터로 이해해야 합니다. 코드만 보지 말고 코드를 실행 디버그 또는 로그로 흐름을 확인하거나 요구사항 명세서, 테이블 구조도 등으로 확인하는게 맞습니다.합의 또는 규약에 따라 VO 를 사용하는 것도 문제가 됩니다. 합의는 변경될 수 있고 교체될 수 도 있습니다. 내용 결합으로 만들어진 VO 는 리펙토링이 어렵기 때문에 변경 비용이 증가됩니다. 합의 또는 규약은 VO 가 아닌 기능을 구현할 수 있는 비즈니스 로직에서 정의하고 처리해야 합니다.내용 결합이기 때문에 VO 간 데이터를 전달하는 get, set 코드가 반복됩니다. 개인적으로 정말 쓸모 없는 코드입니다.VO 는 시간이 지날 수록 유사한 데이터가 추가됩니다. 예를 들어 int 급여, String 형식화된급여, long 억단위가넘는_금여 등 유사한 멤버데이터(객체)가 추가되고 VO 는 알아볼 수없게 됩니다. 물론 리펙토링도 힘들기 때문에 고치기도 어렵습니다.데이터 중복을 제거하기 위해 정규화된 데이터를 사용하게 되고 원래의 데이터를 가져오기 위해 조인을 사용합니다. 이를 VO 로 표현하다 보면 유사하고 중복된 VO 가 만들어지는걸 보게 되는데 VO 때문에 코드가 복잡해지는 원인이 됩니다.전 Map 을 사용합니다. 자동화 하기도 쉽고 실행시점에 객체를 결정할 수 있는 데이터 결합을 유도시키기 좋기 때문입니다. 물론 Map 도 단점이 있어 그대로 사용하지 않고 Null 안정성, 디폴트 값, crone, 테이블 등의 기능을 추가해 사용합니다. 그리고 카멜표현법이 간혹 오타를 발생시키기도 하는데 데이터의 KEY 는 언더바(리니어) 를 사용해 해결합니다.

vo대신 map사용하면 어떤가요?

11개의 답변

Q&A 목록