DTO로 VO와 XML을 사용하는 것에 대한 논쟁

ukira1의 이미지

회사 내부적으로 DTO(Data Transfer Object)설계를 하다가 논쟁이 붙었는데요.
저는 VO를 만들어서 전달하자 라는 생각이고,
저희 기술설계 담당자 께서는 jdom의 Element 형식으로 만들어서 넘기자고 생각하십니다.
(VO방식은 다 아실꺼 같으니 생략하고,'
XML방식의 샘플 코드를 보여드리면,
...
//rs를 얻음
while(rs.next()){
Element elPerson = new Element("Person");
ECCompanyArticle.setAttribute("name", trim(rs.getString("name")));
... //다른 값들 얻어옴
}
//
위와 같이 ResultSet을 날코딩으로 XML형식으로 만듭니다.
처음 봤을때, 너무 로레벨 같다는 생각이 들었습니다.
)

의견차이가 발생한 부분은 다음과 같습니다.

저같은 경우는 VO를 선호합니다.
장점
1. 코드상에 어떤 타입을 이용하는지 명시되므로, 관리의 편의성이 있다.
2. 컴파일 타임에 타입 오류나 변수명 등을 체크해주므로, 개발이 편하다.
3. 디버거 이용 시 변수 값을 그대로 Inspection할수 있다. ( 로그를 이용해서 디버깅하기 위해서는 VO의 toString()등을 구현해줘야함)
4. 새로운 작업자가 할당될 경우 학습 속도가 빠르다.
단점
1. 많은 수의 VO가 생기므로, 관리가 복잡해질수 있다.

XML방식의 경우(솔직히 장점을 잘 모르겠습니다.)
장점
1. 데이터 처리의 유연성이 높다.
2. Value관련 class관리할 필요가 없다.
단점
1. 디버거를 이용한 디버깅이 힘들다. ( 로그를 이용한 디버깅은 쉽다.)

특히 관리상의 편의점이 저는VO방식이 좋다고 하고 담당자는 XML이 낫다고 하는데,
외부와 인터페이스 하는 것이 아닌 내부 통신시에 XML로 날코딩 변환해서 쓰는 것의
장점이 도대체 무엇인지 모르겠습니다.

고수님의 의견 부탁드립니다.

dragonkun의 이미지

저는 요즘 jdom element 로 되어 있는 것을 DTO(VO)를 기준으로 동작하도록 수정하는 작업을 주로 합니다.
저희 같은 경우는 XML로 데이터를 주고받는 것에 대해서 처음 설계가 잘못되서 고생을 많이 했고, 요즘도 한참 고생을 합니다.. -_-

XML 로 데이터를 주고 받으면서 데이터 타입에 대한 고려가 없어서 모든 걸 String 으로 전송되게 됐는데..
타입 체크가 엄격한 PostgreSQL로의 마이그레이션 작업을 하면서 호되게 당했습니다.
MySQL에서는 "123" 도 Integer 필드에 들어가지만 PostgreSQL은 String은 Integer 필드에 못 들어간다면서 에러를 내죠..;;

확실히 외부와 연동할 API 를 고려를 한다면, XML 방식으로 하면 유리한 점이 있겠습니다만..
요즘엔 OXM(Object-XML Mapping) 같은 것도 잘 나오고 해서 굳이 XML 로 작업을 할 이유는 별로 없을 것 같습니다.
---
Emerging the World!

Emerging the World!

creativeidler의 이미지

VO는 사실 PEAA 때문에 용어 혼동이 생긴 건지 정정이 된 건지 알 수 없지만 말씀하시는 VO는 getter setter가 있는 자바빈즈를 말하는 것 같군요. PEAA에서 말하는 VO는 Integer나 String 같은 객체를 가리킵니다. 물론 어느 게 맞다고 딱 잘라 말할 순 없습니다. J2EE 코어 패턴에서는 빈즈를 VO라고 부르거든요.

그렇게 보면 질문은 DTO로 자바빈즈를 쓸 것이냐 DOM 엘리먼트를 쓸 것이냐..하는 것인데..

참고로 DTO로 자바빈즈를 쓸 것이냐 Map을 쓸 것이냐에 대한 논쟁은 이미 있었습니다. 제가 지저분하게 싸웠던 논쟁이라 차마 링크는 못 걸겠고-_- 자바서비스넷에서 검색하면 나올 겁니다.

저는 거기서 Map을 지지했습니다. Map 역시 위에서 이야기한 DOM의 장점이 있습니다. DTO마다 클래스가 늘어날 필요가 없고 유연성이 높습니다. 쿼리 자동화하기도 쉽구요.

DTO로 그냥 빈즈를 쓰는 것은 아마도 J2EE Core Pattern의 DAO 패턴이 될 것입니다. DAO + DTO의 조합이 되는 형태죠. 썬의 영향으로 이 패턴이 많이 퍼졌지만 사실은 AnemicDomainModel이라고 비판받는 패턴입니다. 데이터와 Action이 분리가 되어 있다는 것이죠. 그래서 사실은 DAO와 DTO를 합친, 즉 DomainModel이 DAO 역할도 하면서 동시에 DTO 역할도 하는 것이 더 권장되는 패턴입니다. Rails 등의 최신 프레임웍들이 그렇죠.

하지만, 사실 DAO 패턴도 나름의 유용성이 있습니다. ORM을 쓰지 않을 경우에는 DAO 패턴이 조금 더 개발하기도 쉽고 성능 튜닝하기도 쉽습니다. DomainModel은 어디서 쿼리가 날아갈지 통제하기가 쉽지 않거든요. 그래서 자바에서는 DAO 패턴이 아직 널리 쓰이고 있죠. 그런데, 이 경우에는 DTO가 단순 데이터 전달 밖에 안합니다. 이런 용도로 매번 클래스를 만드는 것은 조금 낭비죠. 그런데 이 경우 Map은 클래스를 만드는 낭비가 없고 유연합니다.

Validation하기도 Map이 조금 더 편합니다. Annotation만 살짝 활용하면 일괄적으로 적용할 수 있는데 빈즈는 리플렉션을 써야 합니다.

컴파일 타임의 문제라든가 하는 건 거의 차이가 없습니다. 양쪽 모두 많이 해봤는데 실제로 효율성의 차이는 컴파일 타임 타입 검사보다도 IDE의 자동완성에 있습니다. 자동완성이 된다는 건 정말 좋은 일이죠. ^^

하지만, 불행히도 이 DTO를 써야 하는 곳, JSP에서는 이 장점이 약해집니다. JSTL의 EL은 아직 자동완성이 안되거든요. 그래서 결과적으로 활용하는 편의는 Map보다 별반 낫지 않습니다.

그런 면에서 DOM 엘리먼트를 사용하면 Map의 장점은 일부 가져올 수 있습니다.

그러나...

DOM 엘리먼트는 Map의 장점들을 아주 일부만 가져옵니다. DAO 패턴에서 DTO 클래스를 많이 만들지 않아도 된다는 장점 하나죠. Map은 strong typing은 아니지만 객체의 타입이 보존되는 반면 DOM은 다 스트링입니다. 게다가 API도 훨씬 쓰기 어렵구요. 그래서 전 자바빈즈 vs DOM이면 무조건 자바빈즈의 손을 들어줍니다. 전 사실 DTO를 DOM으로도 해봤고 심지어 output을 XML로 찍고 xslt로 변환하는 미친 짓도 해봤는데 다 바보짓이었습니다.

제가 생각하는 순위(?)는 이렇습니다. 1등 도메인 모델 + 캐시, 2등 DAO + Map(DTO), 3등 DAO + 빈즈(DTO), 4등 도메인 모델 only, ................................................., 100000등 XML

ukira1의 이미지

답변 감사드립니다.