Freigeben über


Private Data Members

Why does a data contract with private or internal members generate a proxy with public fields?

The obvious answer is that the representation for data contracts doesn't contain information about member visibility but that just leads to the question of why the information isn't preserved by the representation.

If we take a data contract that contains both public and private members,

 [DataContract]
class Data
{
   [DataMember]
   public int i;

   [DataMember]
   private string s;
}

Then, the type representation used to generate a proxy is based on an XML schema.

 <xs:schema xmlns:tns="https://schemas.datacontract.org/2004/07/" elementFormDefault="qualified" targetNamespace="https://schemas.datacontract.org/2004/07/" xmlns:xs="https://www.w3.org/2001/XMLSchema">
  <xs:complexType name="Data">
    <xs:sequence>
      <xs:element minOccurs="0" name="i" type="xs:int" />
      <xs:element minOccurs="0" name="s" nillable="true" type="xs:string" />
    </xs:sequence>
  </xs:complexType>
  <xs:element name="Data" nillable="true" type="tns:Data" />
</xs:schema>

A schema is a type system that is independent of the type system used by the proxy and has no concept of member visibility. However, by saying that a member is part of the data contract, you've effectively said that that member is as intrinsically part of the data as any other public facing member. Member visibility is a facet of information hiding to suppress details that are not needed by other parts of the system, but a data member by definition is needed by other parts of the system. Therefore, regardless of how one of the parties has chosen to represent that data, it's more likely than not that the other side will need to manipulate that data to uphold the contract.

Next time: Generating Types with Lists

Comments

  • Anonymous
    May 05, 2008
    Today wraps up the series on detailed messaging changes in Orcas. You can get the whole series here as