WCF-도메인 개체 및 IExtensibleDataObject

Question

일반적인 시나리오. 서버 팜과 여러 분산 및 로컬 클라이언트 간의 통신을 위해 구식 XML 웹 서비스 internally 를 사용합니다. 제 3자가 관여하지 않으며, 우리 자신과 고객이 사용하는 애플리케이션 만 있습니다.

우리는 현재 XML WS에서 WCF/object-based 모델로의 이동을 고민하고 있으며 다양한 접근 방식을 실험하고 있습니다. 그중 하나는 도메인 개체 / 집계를 직접 유선으로 전송하여 DataContract 속성을 호출하는 것입니다.

IExtensibleDataObject의 Order 속성을 사용하는 DataContract 및 DataMembers를 사용하면 간단한 속성 버전 관리 문제에 대처할 수 있습니다 (모든 클라이언트를 제어하고 쉽게 강제 업데이트 할 수 있음).

전송 전용 데이터 전송 객체 (DTOs)를 유선으로 사용해야한다는 말을 계속 듣고 있습니다.

왜? 그래야 할 이유가 있습니까? 우리는 서버 측과 클라이언트 측에서 동일한 도메인 모델을 사용합니다. 물론 옳고 "필요한"것으로 간주되는 경우에만 컬렉션을 미리 채 웁니다. 컬렉션 속성은 서비스 로케이터 원칙과 IoC를 사용하여 데이터를 직접 (서버 측에서) 가져 오기 위해 NHibernate-based "service"를 호출하고, WCF 서버 팜과 통신하기 위해 클라이언트 측에 WCF "service"클라이언트를 호출합니다.

그렇다면 왜 우리는 DTOs를 사용해야합니까?

Answer 1

내 경험상 DTO는 다음과 같은 경우에 가장 유용합니다.

1. 유선을 통해 전송 될 내용을 엄격하게 정의하고 해당 정의에 특화된 유형을 갖습니다.
2. 나머지 애플리케이션, 클라이언트 및 서버를 향후 변경으로부터 격리
3. 비 .Net 시스템과의 상호 운용성.DTO는 확실히 필수는 아니지만 "안전한"유형을 더 쉽게 설계 할 수 있습니다.

   귀하의 시나리오에서 이러한 디자인 기능은 그다지 중요하지 않을 수 있습니다.엄격한 DTO 및 공유 도메인 개체와 함께 WCF를 사용했으며 두 시나리오 모두 훌륭하게 작동했습니다.유선을 통해 도메인 개체를 보낼 때 내가 알아 차린 유일한 점은 필요한 것보다 더 많은 데이터를 (예기치 않은 방식으로) 보내는 경향이 있다는 것입니다.이것은 다른 무엇보다 WCF에 대한 경험이 부족했기 때문일 것입니다.그러나 당신이 그 길을 가기로 선택한다면 그것은 당신이 확실히 조심해야 할 것입니다.

Answer 2

두 접근 방식 (공유 도메인 개체 및 DTO)으로 작업 한 경험이있는 경우 공유 도메인 개체의 큰 문제는 모든 클라이언트를 제어하지 않을 때라고 말하고 싶지만, 과거 경험에서 나는 개발하지 않는 한 일반적으로 DTO를 사용했습니다.속도가 가장 중요했습니다.

항상 클라이언트를 제어하지 못할 가능성이있는 경우 DTO를 권장합니다. 도메인 개체를 다른 사람의 클라이언트 응용 프로그램과 공유하자마자 내부 정보를 다른 사람의 개발자와 연결하기 시작하기 때문입니다.주기.

또한 버전이 지정된 서비스 환경에서 작업 할 때 DTO가 유용하다는 것을 발견했습니다. 따라서 앱의 내부를 근본적으로 변경할 수 있었지만 여전히 이전 버전의 서비스 인터페이스에 대한 호출을 수락 할 수있었습니다.

마지막으로 클라이언트 애플리케이션이 많은 경우 쉽게 버전을 지정할 수있는 서비스로 보호되므로 DTO를 사용하는 것이 좋습니다.