2013-06-26 1 views
0

내 프로젝트 (WCF REST Service)에서 두 가지 접근 방식을 단계적으로 수행했습니다.REST WCF - 엔티티를 노출하거나 사용자 정의 클래스를 Entity 클래스로 변환하는 가장 좋은 방법

  1. 전체 OData 서비스 스택을 지원하기 때문에 시작되었지만 CRUD 작업에 대한 유효성 검사 요구 사항이 많아서 EF로 'WCF 서비스'로 전환되었습니다.
  2. 이제 셀프 추적 엔티티를 사용하여 클라이언트에 엔티티를 노출하는 방법을 생각해보십시오. 많은 기사에서 STE는 Microsoft에서 더 이상 지원하지 않으며 OData를 사용하기를 원합니다 (그러나 WCFDataService는 나에게 적합하지 않습니다).

클라이언트보다 내 엔티티를 노출시키는 데 가장 좋은 디자인은 무엇입니까? 또는 엔티티 모델의 사용자 지정 클래스 (데이터 계약)를 작성해야 할 수도 있습니다. 그러나 이렇게하면 코드가 증가하여 (사용자 지정 항목과 엔터티간에 개체를 변환 할 때) 코드가 유지되고 유지 관리가 줄어 듭니다.

내 개체를 노출시키는 데 가장 좋은 방법이 있는지 제안 해주세요. 귀하의 제안은 소중하고 감사합니다.

답변

0

Fowlers 분산 객체 디자인의 첫 번째 법칙에서는 "객체를 배포하지 마십시오."라고 명시합니다. 이것은 단지 실제 엔티티 자체가 아닌 사본을 제공한다는 의미입니다. 데이터 계약 네임 스페이스에 엔티티의 미러 사본을 만드는 경우 데이터베이스 스키마를 변경해야하는 경우 훨씬 더 많은 유연성을 유지할 수 있습니다. 데이터 계약이 처음 엔 엔티티와 동일하다면 AutoMapper와 같은 도구를 사용하면 작성해야하는 모든 변환 코드가 제거됩니다. 일단 데이터 계약에 엔티티를 변환, 구성은 1 라이너가된다 :

Mapper.Map<CustomerDto>(customer); 

이 고객 엔티티를 받아 다시 새로운 고객 DTO 당신을 제공합니다. 모든 컨벤션을 기반으로하며 속성 이름을 일치시켜 작동합니다. 데이터 계약이 엔티티와 완전히 동일하지 않은 경우라도 자체적으로 알아낼 수없는 속성에 대해서만 AutoMapper를 프롬프트하면됩니다.

+0

동의합니다, 감사 마크. 나는 처음에는 모든 민감한/불필요한 필드를 노출시키지 않기 위해 DTO가 필요합니다. 매퍼 (mapper) 사용법을 설명하는 예제 링크가 있습니까? fooDTO에 다른 ObjectContext가 필요 없다고 말하면서 잘못되었다는 것을 알려주십시오. 나는 foo의 ObjectContext만을 가질 것이다. 감사합니다 –

+0

수정. 매핑은 데이터가 어디서 왔는지에 관계없이 절대적으로 관련이 없습니다. 이것을 시도하십시오 : http://automapper.org (Nuget을 통해 다운로드 가능) 또한 이것이 귀하의 질문에 대한 해결책이라면, 올바른 것으로 표시해 주시겠습니까? 감사합니다. – MJM