Java beans, VO, DTO, POJO

베스트 댓글 첫번째 단락 :: 자바빈은 Sun 에 의해 정의된 자바빈즈관습을 따르는 클래스입니다. 위키피디아는 자바빈즈가 무엇인지에 대해서 다음과 같은 좋은 요약을 가지고 있죠.. 

자바빈은 자바를 위한 재사용가능한 소프트웨어 컴포넌트로, 시각적인 빌더툴에서 생성가능합니다. (역주: 자바빈이 빌더툴에서 비롯된 ? ) 실제로 이 클래스들은 특정 컨벤션을 따르는 자바 프로그래밍언어로 쓰여졌습니다. 자바빈은 많은 객체들을 단일 객체로 캡슐화(the bean)하여서 여러개의 독립적인 객체보다는 하나의 단일 객체로 전달되게 하여집니다. 자바빈은 serialize할 수 있는 자바 객체로 nullary (?) 생성자를 가지고 있으며 게터세터 메서드를 사용하여 접근가능한 프로퍼티를 가지고 있습니다.

자바빈클래스로 기능하기 위해, 객체클래스는 메서드 네이밍이나 생성자, 행위에 관련된 컨벤션들을 따라야하는데요.. 이러한 컨벤션들은 자바빈을 결합하고(?), 대체하고, 재사용하고 사용할 수 있는 도구들을 가질 수 있게 합니다.

요구되는 컨벤션은

:: 클래스는 퍼블릭 기본 생성자를 가지고 있어야 하며 이것은 편집하거나 사용하는 프레임워크내에서 손쉽게인스턴스화하게 해줍니다.

클래스 프로퍼티는 게터,세터, 다른 메서드(액세서메서드나 mutator메서드로 불리는) 에 의해 접근가능하여 하며 표준 작명 컨벤션을 따라야 합니다. 이것은 프레임워크 내에서나 프로퍼티의 다양한 타입을 사용하느 커스텀 에디터같은 것들에서 손쉽게 자동화된 검사나 빈의 상태를 수정하게 해줍니다.

클래스는 직렬화가능해야합니다. 이것은 어플리케이션이과 프레임워크가 확실하게 빈의 상태를 VM이나 플랫폼에 독립적으로 저장, 복구하게 해줍니다.

인터페이스를 구현하는 것 대신에 이러한 요구사항들이 관습으로 표현되면서 몇몇 개발자들은 자바빈즈를 특정 네이밍 컨벤션을 따르는 plain Old java 객체로 생각합니다.

===

Plain Old Java Object 나 POJO 는 초기에 javax.ejb를 구현하지 않고 무거운 EJB 2.x 에 반대되는 개념으로써, 간단한 경량화 자바 객체로 소개되었습니다. (특별히 엔티티빈즈 무상태 세션빈들은 그렇게 나쁘지 않습니다? IMO ?? 라는 내용이 뭔지..음. ) 오늘날 이 용어는 어떤 어떤 여분의 것을 가지지 않은 단순한 객체를 가리키는데 사용됩니다. 다시 한번 적자면 위키피디아에서는 POJO 에 관해서 다음의 정의를 가지고 있습니다. 

POJO 는 Plain Old Java Object 의 약어로 이 이름은 특별한 오브젝트가 아닌 일반적인 자바객체라는 것을 강조하는데 사용됩니다 (특별히 EJB 이전에 사용된 EJB가 아닌 것을 강조하는데..!) 이 용어는 마틴파울러, Rebecca parsons, Josh mackenze 가 2000년 9월에 사용하기 시작했습니다. 

"우리는 왜 수많은 사람들이 그들의 시스템에서 단순한 오브젝트가 괜찮은 이름이 없다면서 보통의 객체를 사용하는데 반대하는데 지 놀라웠습니다. 우리는 그래서 제법 괜찮은 이름을 주었죠..?" 

이 용어는 새로운 기능을 사용하지 않는 오래된 기술용어의 패턴으로 계속되어집니다 (POTs 나 pods) (중략)

이 용어는 복잡한 객체 프레임워크들에 대해 반대되는 쉽고 평범함에 대한 수요로 인해 널리 받아들여지게 됩니다. 자바빈은 직렬화가능하고 아규먼트가 없는 생성자를 갖고 있으며 게터세터를 갖고 있는 POJO 입니다. 엔터프라이즈 자바빈은 단일 클래스가 아니며 전체적인 컴포넌트 모델입니다 (다시 한번 적자면 ejb3 에서는 엔터프라이즈 자바빈즈의 많은 복잡도를 줄였습니다)

POJO를 사용하는 디자인들이 점점 더 흔해짐에 따라, 프레임워크내에서 POJO를 사용하는 시스템들이 떠오르기 시작하며 그 기능이 실제로 필요한 곳에서 좀더 선택되어졌습니다. 하이버네이트나 스프링이 그 예입니다.

===

VO

Value Object 나 VO는 java.lang.Integer 같은 객체로 값을 가지고 있습니다 (그러므로 값객체입니다) 더 많은 정보를 얻기 위해서 저는 Value Object에 대한 마틴파울러의 설명을 보곤 합니다.

엔터프라이즈 어플리케이션 아키텍쳐 패턴에서, 저는 밸류 오브젝트는 돈이나 날짜범위같은 작은 객체로 설명합니다. 그들의 키 프로퍼티는 참조형 의미라기보다는 값 의미(semantics)를 따른다는 것입니다. 

당신은 보통 값 객체들을 식별할 수 있을 텐데 이것은 동등(equality)의 개념이 동일성(identity)에 있는 것이 있는 것이 아니라 두 값 객체의 필드들이 같으면 그 두 값 객체는 같기(equal)때문입니다. 비록 모든 필드가 같다고하더라도 당신은 유일하다면 당신은 모든 필드를 비교할 필요가 없습니다.(예를 들자면 통화 객체를 위한 통화 코드들은 동등성을 테스트하기에 충분합니다.)

일반적인 휴리스틱( heuristic ?) 은 값객체는 전적으로 불변(immutable)이어야 한다는 것입니다. 만약 당신이 값 객체를 바꾸고싶다면 당신은 해당 객체를 새로운 것으로 대체(replace)해야 하며 값 객체의 값을 수정하지 말아야 합니다. 수정할 수 있는 값객체는 재명명(aliasing)문제에 이르게 됩니다. 

예전의 J2EE 문헌에서는 값 객체를 다른 개념을 설명하는(제가 DTO 라 부르는 ) 데 사용하였습니다. 그것들은 (DTO) 그들의 사용법을 바꿔왔고 Transfer Object라는 용어로 사용됩니다.

당신은 값 객체에 대한 좋은 자료를 wiki나 dirk reihle에게서 찾을 수 있을 것입니다.

===

Data Transfer Object

(Data Transfer Object)데이터 전송 객체나 DTO는 EJB에서 소개된 (안티)패턴입니다. EJB에서 원격호출을 수행하는 대신에 네트워크를 통해서 전송될 수 있는 값 객체에 데이터를 캡슐화하자는 생각이었습니다. 위키피디아에서는 DTO에 대해 다음과 같은 개념을 설명합니다.

DTO는 전에 VO로 불렸는데 소프트웨어 어플리케이션 하위시스템간에 데이터를 전송하기 위한 디자인 패턴입니다. DTO들은 종종 데이터 액세스 오브젝트와 함께 사용되어서 데이터베이스로부터 데이터를 다시 얻는데 사용되곤합니다. 

DTO와 비지니스 객체나 데이터액세스객체간의 차이는 DTO는 그것 자신의 데이터를 얻거나 저장하는 것 외에 어떤 행동을 가지고 있지 않다는 것입니다. 

전통적인 EJB아키텍쳐에서 DTO는 두가지 목적을 합니다. 첫번째, 이것들은 엔티티빈들이 직렬화되지 않는 문제들을 해결하니다. 두번째로 DTO들은 컨트롤러에서 프레젠테이션 티어로 반환되기 이전에 암시적으로 뷰에 사용되는 모든 데이터가 DTO로 페치되고 마샬되는 조립면?(assembly phase)를 정의합니다.