WCF: 속성 대 구성원의 DataMember 특성

WCF: 속성 대 구성원의 DataMember 특성

---

wcf에서 DataMember속성에 속성을 적용하는 것의 차이점은 무엇입니까?

private int m_SomeValue;

[DataMember]  
public int SomeValue {
  get {...}
  set {...}
}

멤버 변수 대신

[DataMember]  
private int m_SomeValue;

public int SomeValue {
  get {...}
  set {...}
}

?

---

일반적으로 개인 필드보다는 속성에 DataMember 특성을 적용하는 것이 좋습니다. 속성을 필드에 대신 적용하는 유일한 이유는 속성이 읽기 전용인 경우(즉, 설정자가 없는 경우)입니다.

---

Name마커 를 사용하기만 하면 필드를 사용하든 속성을 사용하든 계약은 동일합니다.

[DataMember(Name="SomeValue")]
private int m_SomeValue;

그러나 특히 Silverlight 및 CF에서 비공개 멤버에 액세스하는 데 몇 가지 권한 문제가 있을 수 있습니다. 이 경우 공용 속성을 데이터 멤버로 사용하는 것이 좋습니다. 사실 나는 아주 좋은 이유가 없으면 항상 부동산을 사용하는 경향이 있습니다 ...

---

속성이 아닌 필드를 DataMember 로 표시하는 데에는 충분한 이유가 있습니다.

자세한 내용은 다음을 확인하십시오. http://blog.walteralmeida.com/2010/05/wcf-and-datacontract-serialization-internals-and-tips-.html

그건 그렇고: ContractSerializers는 완전 신뢰 환경에서 실행되는 경우에만 DataMemberAttribute가 있는 모든 개인 필드를 직렬화 합니다 . 부분 신뢰에서는 작동하지 않습니다(해결 방법은 위에 나열된 블로그 확인).

---

이 결정은 WCF 서비스 사용에 따라 다릅니다.

1. 동일한 도메인 모델을 공유하는 자체 .NET 시스템에서 사용하는 내부 서비스입니다.
2. 동일한 도메인 모델을 공유하지 않는 다른 플랫폼에서 사용하는 외부 서비스입니다.

사례 1.

직렬화 - 개체의 상태를 유지하는 프로세스입니다. C#에서 개체의 상태는 해당 데이터 필드로 표시됩니다.

C#의 속성은 기본적으로 개체의 상태를 조작하는 메서드입니다. 속성을 사용하면 속성이 설정되는 순서가 최종 데이터 상태에 영향을 줄 수 있기 때문에 역직렬화 시 다른 개체 상태가 발생할 수 있습니다. 예를 들어 메서드(속성 집합)가 현재 DateTime과 같이 변경되는 일부 컨텍스트에 의존하는 경우 다른 요인으로 인해 잘못된 상태 역직렬화가 발생할 수도 있습니다.

캡슐화에 대해 말할 수 있습니까? 내 개체가 잘못된 상태가 되는 것을 원하지 않으며 유효성 검사, 개체 그래프 무결성 검사 등을 수행해야 합니다. 예, 해야 합니다. 그래서 DataMember 속성을 props에 넣습니까? 아니요.

여기서 문제는 많은 사람들이 도메인 엔터티와 DTO(데이터 전송 개체, WCF 계약)라는 두 가지 다른 것을 혼합한다는 것입니다. 필요한 것은 수신한 데이터가 전송된 데이터와 완전히 동일한지 확인한 다음 이 데이터에서 유효한 도메인 엔티티를 구성할 수 있는지 확인하는 것입니다. 이를 달성하는 가장 좋은 방법은 DTO에 대해 별도의 클래스를 사용하고 이들로부터 도메인 엔티티를 구성하는 것입니다.

그러나 대부분의 프로그래머는 게으르며 DataMemeber 속성으로 Domain Entity를 간단하게 장식하는 것을 좋아합니다. 이 경우 필드 또는 Prop 결정은 유효성 검사 논리가 있는 위치에 따라 다릅니다. 유효성 검사 논리가 Set 메서드에 묻혀 있으면 Props를 사용해야 하고, 외부인 경우 Fields를 사용하고, 역직렬화 후 도메인 엔터티의 유효성을 검사해야 합니다.

추신: 데이터베이스 지속성과 같은 직렬화 프로세스에 동일한 규칙이 적용된다고 생각합니다.

Also, I would like to mention that Silverlight can't serialize\deserialize private fields, because you can't access them from outside using reflection, and you will have to make them private and use InternalsVisibleToAttribute.

Case 2.

This is hard one. The main focus here is interoperability. In 99.9% you will have separate DTO classes in this case and most likely lot's of different versions of them to support old clients. It doesn't matter where you put DataMembers attribs in this, because you use DTO's. I will not bother with explaining this scenario, because developers who work on such large scale system are usually quite experienced, and they don't bother reading SO.

---

In theory, and as long as you keep m_SomeValue always equal to SomeValue (like a simple getter/setter), nothing. Other than the name of the variable exposed by the WCF. (Obviously, if you tag the m_ variable, then your proxy class will also have the same m_ name. The proxy class will generate a public property whether you use a public/protected/internal/private field or property.

However, if you have any special logic in your accessors that may modify the value returned (ToUpper()ing a string, for example), then you would return a different value.

---

Personally I would just use the property and completely removed the member variable all together. i.e.

[DataMember]
public int SomeValue
{ get; set; }

The property will inexplicably create a member variable behind the scenes.

---

If add [DataMember] on private int m_SomeValue, this member can not be serialization,so must be add it on public int SomeValue.

[DataMember]  
private int m_SomeValue;

public int SomeValue {
  get {...}
  set {...}
}

the code of above can not be get value in the client if you use it through WCF.

ReferenceURL : https://stackoverflow.com/questions/556775/wcf-datamember-attribute-on-property-vs-member