ADO.Net 데이터 서비스를 통해 부분(Entity Framework) 클래스에 정의된 읽기 전용 속성을 어떻게 사용합니까?

Question

Entity Framework에서 정의한 개체가 있고 부분 클래스를 통해 추가 메서드와 속성을 추가했습니다.나는 이 작업에 대한 대부분의 제한 사항을 이해한다고 생각하지만, 내가 보고 있는 것을 확인하고 싶었습니다(또는 이 작업을 수행하기 위해 수행해야 할 작업이 무엇인지 배우고 싶었습니다).

몇 가지 항목을 사용하여 읽기 전용 계산 필드를 만드는 읽기 전용 속성이 있는 부분 클래스가 있습니다.내가 희망/기대했던 대로 읽기 전용 속성이 ADO.Net 데이터 서비스를 통해 다시 돌아오지 않는 것이 궁금했습니다.즉.나는 엔터티 프레임워크의 속성과 부분 클래스를 통해 코드에서 정의되는 속성이 데이터 서비스 호출을 통해 제공되기를 기대했습니다.

이것이 사실입니까?ADO.Net Data Services가 데이터를 쿼리할 때 부분 클래스가 완전히 무시됩니까?그렇다면 엔터티에 읽기 전용 유형 속성을 가져오는 가장 좋은 방법은 무엇입니까? (다른 네임스페이스가 있는 동일한 부분 클래스를 잘라내어 클라이언트 측과 서버 측 코드 베이스 모두에 붙여넣는 것을 피하고 싶기 때문입니다.)

Answer 1

Microsoft 포럼 게시물에서:(여기에서 전체 게시물을 확인하세요)

"나는 당신이"EF 제공 업체가 노출시키는 기존 엔터티에 읽기 전용 속성을 추가하는 방법 "이라고 생각하십니까?V1에서는 좋은 방법이 없습니다.EF의 경우 EF 메타 데이터 API를 사용하여 메타 데이터를로드하므로 반사하지 않습니다.따라서 부분 클래스를 통해 추가 한 추가 속성은 무시됩니다.

Astoria에는 아직 읽기 전용 속성 개념이 없습니다.따라서 모델의 일부가 아닌 다른 속성을 노출 시키면 업데이트에서이를 처리하는 방법을 모릅니다.우리는 서버에서도 데이터를 실질적으로 잃고 싶지 않습니다. "

따라서 이는 ADO.Net 데이터 서비스를 통해 노출될 수 없는 기능인 것 같습니다.

Answer 2

여기에는 기본 모델(EF)과 WCF/mex 계층이라는 두 가지 별도의 문제가 있습니다.추가 속성은 edmx 모델의 일부가 아니지만 문제가 WCF/mex 측면과 더 관련이 없는지 궁금합니다.

그러나 작동하더라도 ADO.NET Data Services는 데이터, 아니다 논리.따라서 계산된 속성에 의존하는 것은 안전한 옵션이 아닙니다.클라이언트에는 공식이 없고 원래 값만 있습니다.

그것이 무엇인지 알아내려면 속성을 읽기/쓰기로 설정하고(쓰기가 유용한 작업을 수행하지 않더라도) 값에 [DataMember] 속성 등이 있는지 확인하십시오.

Answer 3

문제는 XML 직렬화를 사용하면 get 및 set 메서드를 사용하여 속성만 직렬화한다는 것입니다.그렇지 않으면 역직렬화할 수 없습니다.속성에 빈 집합 메서드를 추가하고 진행 방법을 확인하세요.

롭