데이터 전송 객체, 도메인 개체 및 리포지토리

Question

나는이 모든 것이 어떻게 함께 작동하는지 알아 내려고 노력하고 있습니다. DTO는 기본적으로 도메인 객체가 양식 등으로 전달할 수있는 데이터 컨테이너 일뿐입니다. 도메인 객체에 DTO가 포함되어 있거나 DTO를 수행하고 도메인 오브젝트는 수동으로 매핑 될 것과 동일한 속성을 모두 갖는 것입니까?

서비스에 DTO 유형을 노출시키는 경우 클라이언트의 각 GET/SET 작업에 대한 왕복 여행을 작성하지 않고 Getters 및 Setter를 어떻게 사용합니까? 나는 당신이 하나의 긴 생성자를 가질 수 있다는 것을 알고 있지만, 당신이 7 개 이상의 속성이 있으면 못 생겼을 수 있습니다.

저장소 패턴을 구현할 때 DTO 또는 도메인 개체를 전달합니까?

Answer 1

• DTO와 도메인 객체는 분리되어야합니다.
• DTO를 도메인 객체에 그리고 도메인 객체를 DTO에 맵핑하는 맵퍼가 있어야합니다. 이 맵퍼는 기본 맵퍼가 반사를 사용하여 객체를 서로 맵핑하는 인터페이스를 구현해야합니다.
• 저장소는 도메인 객체를 반환하는 서비스 여야하며, 이는 자체가 서비스해야합니다.
• DTO가 웹 서비스에 노출 된 클래스 인 경우, 생성 된 WSDL은 속성을 요소로 정의하고 다른 쪽에서 생성되는 프록시는 클라이언트 자체에서 실행되는 getter / setter 속성을 만듭니다. , 따라서 getters와 setters는 왕복을 일으키지 않습니다.
• DTO에서 공개 변수 만 만들더라도 프록시는 getter and setter로 구현됩니다.

Answer 2

DTO에 DTO의 소비자가 도메인 객체를 사용하여 시작할 수 있도록 DTO에 도메인 객체에 대한 참조를 포함하는 것이 낫다고 생각합니다. 즉, DTO의 소비자가 도메인 객체를 돌연변이하지 않아야하는 경우 DTO에 도메인 객체에 캡슐화 된 값이 포함되어 있어야 할 수도 있습니다. 도메인 객체의 깊은 사본을 수행해야 할 수도 있기 때문에 어려울 수 있습니다.

서비스로 DTO 유형을 노출시키는 것이 왜 Getters/Setter를 사용하여 왕복 여행을하는 것이 문제인지 잘 모르겠습니다. 서비스가 원격 서비스 인 경우 반품 된 DTO는 어쨌든 직렬화되고 Getters/Setters는 값의 사본을 얻습니다. 서비스가 원격이 아닌 경우 클라이언트와 서비스가 동일한 프로세스 공간에 있기 때문에 "왕복"을하는 것은 큰 페널티가 아닌 것 같습니다.